É possível usar o Google Cloud para hospedar soluções de recuperação de desastres para sistemas SAP em execução no Google Cloud, no local ou em outro provedor de nuvem.
Definição de recuperação de desastres
Recuperação de desastres e alta disponibilidade (DR e HA, respectivamente na sigla em inglês) são dois elementos distintos de um conceito mais amplo, a continuidade de negócios. Este guia aborda a recuperação de desastres.
Uma solução de DR está pensada para restaurar o processamento de aplicativos depois de um desastre natural ou causado pelo homem ou uma falha na infraestrutura provocar uma interrupção em larga escala. Essas interrupções desativam não apenas o sistema principal de processamento de aplicativos, mas também qualquer sistema em espera que garanta uma proteção contra falhas do sistema ou da infraestrutura local de pequena escala.
Veja a seguir outras características de uma solução de DR que a diferenciam de uma solução de alta disponibilidade:
- O sistema de recuperação em uma solução de DR normalmente não é um sistema de espera ativa.
- Um procedimento de recuperação de desastres geralmente requer intervenção manual para recuperar ou restaurar o processamento de aplicativos a partir de backups ou replicação de dados, sistemas e infraestrutura.
- A solução inclui um local de recuperação que está em uma região geográfica diferente do sistema principal.
- O objetivo do tempo de recuperação (RTO, na sigla em inglês) de uma solução de recuperação de desastres geralmente é medido em horas, se não dias.
O exemplo de arquitetura a seguir mostra um sistema SAP que inclui uma solução de alta disponibilidade e uma solução de DR. O local de DR, em que o sistema será restaurado após um desastre, se encontra à direita, na parte Region 2. O sistema principal está à esquerda, na parte Region 1 e está configurado para alta disponibilidade com clusters de failover que abrangem duas zonas. A função de backup da solução de DR é representada por linhas tracejadas que abrangem as duas regiões. Para armazenamento, os sistemas usam um bucket do Cloud Storage multirregional, mostrado na parte inferior do diagrama.
O exemplo também mostra um banco de dados. A recuperação de aplicativos depende da recuperação de dados, mas os procedimentos de DR para sistemas de banco de dados não são abordados neste guia. Consulte a documentação do banco de dados e quaisquer observações de SAP aplicáveis. Neste guia, nos concentramos especificamente no sistema SAP NetWeaver (SAP ASCS/ERS) e nos servidores de aplicativos (SAP e AAS).
Para informações sobre como implementar sistemas SAP de alta disponibilidade no Google Cloud, consulte o Guia de planejamento de alta disponibilidade para SAP NetWeaver no Google Cloud.
Para informações sobre alta disponibilidade e recuperação de desastres para o SAP HANA no Google Cloud, consulte o Guia de planejamento de alta disponibilidade do SAP HANA e o Guia de planejamento de recuperação de desastres do SAP HANA", respectivamente.
Para informações gerais sobre DR no Google Cloud, consulte Guia de planejamento de recuperação de desastres.
Abordagens de design de DR para sistemas SAP não executados no Google Cloud
Se seu sistema SAP principal não é executado no Google Cloud, é possível usar a abordagem de migração lift-and-shif para DR, na qual a arquitetura e o software do sistema de DR no Google Cloud são os mesmos do sistema principal. Também é possível adotar uma abordagem nativa da nuvem, na qual, como parte do design da solução de DR, você otimiza o sistema recuperado para a nuvem por meio dos produtos ou serviços do Google Cloud ou de parceiros do Google Cloud.
Caso use uma abordagem de migração lift-and-shift, precisará confirmar que a arquitetura do sistema principal é totalmente compatível com o Google Cloud. Para qualquer uma dessas abordagens, será preciso verificar se todos os softwares usados estão devidamente licenciados para uso no Google Cloud.
Para mais informações sobre licenciamento, consulte os Termos de Serviço do Google Cloud Platform.
Elementos de design de uma solução de DR para SAP NetWeaver no Google Cloud
Os elementos de design de uma solução de DR para SAP NetWeaver no Google Cloud podem incluir o seguinte:
- Localização do local de DR
- Rede
- Segurança
- Considerações sobre máquina virtual (VM, na sigla em inglês)
- Opções de backup
- Armazenamento
Para implementar cada um desses elementos de design, você tem várias opções para atender aos seus objetivos de recuperação e custo.
Localização do local de DR
Ao escolher uma região do Google Cloud para sua localização de DR, considere:
- a área de impacto potencial de qualquer desastre que possa ocorrer no local principal;
- a localização dos usuários do sistema SAP NetWeaver;
- se os recursos do Google Cloud usados pelo sistema SAP estão disponíveis na região e na zona escolhidas.
Escolha uma região do Google Cloud para a localização de DR que esteja suficientemente longe da principal, de modo que o local de DR não seja afetado por desastres na origem. Uma distância de 161 quilômetros ou mais é geralmente considerada suficiente, mas regulamentos ou diretrizes organizacionais podem exigir uma distância mínima diferente.
Se o sistema SAP principal é executado no Google Cloud, coloque seu local de DR em qualquer região do Google Cloud próxima aos usuários, exceto na região onde o sistema principal esteja sendo executado. As regiões do Google Cloud estão localizadas suficientemente afastadas uma da outra, de modo que duas regiões do Google Cloud provavelmente não serão afetadas pelo mesmo desastre.
Se seu sistema SAP principal é executado fora do Google Cloud, coloque o local de DR na região mais próxima possível dos usuários, sem estar na zona de impacto potencial de qualquer desastre que possa ocorrer no local principal.
Na sua região de DR, coloque seu sistema de recuperação de desastres em uma zona que ofereça suporte aos tipos de instância de VM e a outra infraestrutura necessária para os sistemas SAP e de banco de dados.
Depois de selecionar uma região para o local de DR, pode ser necessário aumentar suas cotas de recursos para a região a fim de fornecer recursos suficientes para o sistema de DR antes de um evento.
Para ver os locais de todas as regiões do Google Cloud, consulte Regiões e zonas.
Para ver os recursos disponíveis em cada região, consulte Regiões e zonas disponíveis.
Para analisar quais recursos do Google Cloud são globais, regionais e zonais, consulte Recursos globais, regionais e zonais.
Rede
No Google Cloud, a nuvem privada virtual (VPC) oferece funcionalidades de rede que podem se estender por todo o mundo.
Se ainda não tiver uma rede VPC para seu local de DR, crie uma. Você também precisa criar uma sub-rede e um intervalo de IP para o local de DR.
Se o sistema principal estiver no Google Cloud, a configuração da rede fica mais fácil se o local principal e o de DR estiverem na mesma rede VPC. No entanto, se necessário, é possível colocar os locais principal e de DR em diferentes redes VPC ou mesmo em projetos distintos.
Ao projetar sua solução de DR, é necessário considerar os seguintes caminhos de comunicação:
- A conexão entre o local principal e o de recuperação no Google Cloud
- A comunicação interna entre os aplicativos, bancos de dados e servidores que compõem seu sistema SAP
- A conexão entre seus usuários e o sistema SAP
Para conexões de locais externos ao Google Cloud, há uma variedade de produtos de rede para oferecer suporte a cada um desses pontos de conexão.
Como conectar o local principal ao local de DR
A conexão entre o local principal e o local de DR é necessária para armazenar backups ou fornecer um caminho de replicação entre os dois sistemas, para que os recursos de recuperação estejam imediatamente disponíveis no caso de um desastre e para testar seus procedimentos de desastre.
Se o sistema principal é executado no Google Cloud, disponibilizar seus backups no local de DR é quase automático. Os snapshots do Compute Engine podem ser designados como multirregionais. Outros backups podem ser armazenados diretamente do sistema principal em buckets multiregionais do Cloud Storage para disponibilidade instantânea no local de DR.
Se o sistema principal não é executado no Google Cloud, é possível conectar o local principal à localização de DR no Google Cloud usando Cloud Interconnect ou Cloud VPN.
Para um exemplo de uma topologia de Cloud Interconnect altamente disponível que, com algumas alterações, pode ser adaptada a um cenário de DR, consulte Como estabelecer disponibilidade de 99,99% para Interconexão dedicada.
Para alguns exemplos de topologias de gateway de VPN de várias regiões altamente disponíveis que também podem ser adaptadas a um cenário de DR, consulte Topologias de Cloud VPN.
É muito importante considerar a largura de banda ao configurar sua conexão ao Google Cloud de um local fora da plataforma. A conexão precisa ser totalmente compatível com a transferência regular de dados e backups para o Google Cloud.
Para mais informações sobre suas opções de conexão ao Google Cloud de locais fora da plataforma, consulte Produtos de conectividade híbrida.
Conectividade entre aplicativos, bancos de dados e servidores SAP
Se o sistema principal é executado no Google Cloud, manter a conectividade entre os aplicativos, bancos de dados e servidores SAP no local de DR é relativamente simples: só é necessário modelar nomes de host, sub-redes, firewalls etc. no local principal.
Se o sistema principal não é executado no Google Cloud, pode ser necessário mais esforço na fase de design para converter a arquitetura de rede do local principal para o local de DR no Google Cloud.
Testar seus procedimentos de DR é essencial para identificar e solucionar problemas de conectividade antes que sua empresa precise depender do sistema recuperado.
Como conectar os usuários ao local de DR
Em uma recuperação, depois que o sistema SAP é restaurado no local de DR, o tráfego de seus usuários precisa ser redirecionado para o sistema recuperado. Normalmente, você faz isso atualizando os aliases de rede nas entradas DNS para os novos endereços IP, que são regionais.
Se sua arquitetura de rede usar rotas VPC, atualize as rotas durante a recuperação.
No Google Cloud, é possível usar o Cloud DNS ou outra solução de DNS.
Recursos regionais de rede
Se o sistema principal for executado no Google Cloud e você estiver usando recursos de rede regionais, como o Cloud NAT ou um Cloud Load Balancing, será necessária uma instância do recurso em cada região.
Para mais informações:
Controle de acesso à rede
Verifique se as mesmas portas estão abertas no local de DR e no local principal.
Defina as regras de firewall na sua rede de VPC para controlar o tráfego de e para suas VMs.
Se você tem um serviço do Active Directory no Windows Server, configure-o antes da recuperação e o mantenha sincronizado com a instância do Active Directory no local principal.
Segurança
Você precisa implementar os mesmos controles e permissões de segurança que tem no local principal no local de DR. Os mesmos regulamentos de conformidade também se aplicam ao seu ambiente recuperado.
Qualquer usuário ou papel que exija acesso no local principal também requer acesso ao local de DR.
Para informações gerais sobre projetar a segurança para uma solução de DR no Google Cloud, consulte Como implementar controles de segurança e conformidade.
Considerações sobre VM
É possível acelerar a implantação de instâncias da máquina virtual (VM) do Compute Engine e evitar erros de configuração no seu local de DR usando configurações do Terraform fornecidas pelo Google Cloud, produtos e recursos como o Cloud Deployment Manager, modelos de instâncias e imagens personalizadas.
Como configurar e implantar suas máquinas virtuais
O Google Cloud oferece arquivos de configuração do Terraform e modelos do Deployment Manager para SAP no Google Cloud que podem ser usados para predefinir e implantar o sistema SAP no local de DR. O uso dos arquivos do Terraform ou do Deployment Manager acelera a implantação, reduz erros de configuração e garante que seus sistemas SAP atendam aos requisitos de suporte SAP.
Outra opção para configurar suas VMs antecipadamente são os modelos de instância do Compute Engine. O uso de modelos de instância é uma maneira de acelerar a implantação e reduzir a configuração manual de suas VMs durante a recuperação. No entanto, como eles exigem alguma reconfiguração para o local de DR, pode ser mais fácil recuperar suas VMs com um disco de inicialização de recuperação, conforme descrito na próxima seção.
Consulte Modelos de instância para saber mais.
Também é possível usar ferramentas de orquestração de implantação, como o Terraform, para gerenciar as implantações de infraestrutura no Google Cloud.
Dependendo do seu RTO, é possível pré-implantar suas instâncias do Compute Engine ou, como a implantação de uma VM leva apenas alguns minutos, implantar no momento da recuperação.
Se você pré-implantar suas VMs, será possível interrompê-las para economizar custos ou usá-las para outros fins não essenciais até que sejam necessárias para recuperação.
Também é possível minimizar os custos consolidando um sistema distribuído em menos VMs no local de recuperação. Por exemplo, se os servidores de aplicativos no local principal estiverem em hosts dedicados no mesmo local, no local de DR você poderá colocar os servidores de aplicativos no mesmo host que o SAP Central Services. No entanto, é preciso ponderar a economia de custos em relação à maior complexidade de ter configurações diferentes em cada local.
Disco de inicialização de recuperação
É possível criar uma imagem personalizada a partir do disco de inicialização do host em seu sistema principal e, em seguida, usar a imagem personalizada para criar a instância de recuperação no local de DR.
Se o sistema é executado no Google Cloud, crie uma imagem personalizada, caso tenha criado e modificado um disco de inicialização permanente do Compute Engine no sistema principal. Se você estiver usando uma imagem pública não modificada do Google Cloud, também será possível usar a imagem pública do Google Cloud no local de recuperação. Para mais informações, consulte Como criar, excluir e suspender o uso de imagens personalizadas.
Se o sistema não estiver em execução no Google Cloud, importe uma imagem de disco de inicialização para o Google Cloud do ambiente local ou importe discos virtuais de VMs em execução na estação de trabalho local ou em outra plataforma de nuvem.
Opções de backup
O Google Cloud oferece várias opções de backup diferentes ao projetar uma solução de DR:
- Imagens personalizadas do Compute Engine
- Snapshots de discos permanentes do Compute Engine
- Replicação
Imagens personalizadas do Compute Engine
Para fazer backup do disco de inicialização do sistema principal para uso na recuperação, armazene-o no Google Cloud como uma imagem personalizada do Compute Engine. Para mais informações, consulte Disco de inicialização de recuperação.
Snapshots de discos permanentes do Compute Engine
Para fazer backup do SAP ou de outros sistemas de arquivos que estão em um disco permanente do Compute Engine, é possível usar snapshots de disco permanente.
Também é possível definir um agendamento de snapshots para tirar um automaticamente em intervalos regulares. Consulte Como criar snapshots agendados para disco permanente.
Os snapshots fornecem apenas consistência no nível do bloco. Para garantir a consistência no nível do arquivo, pode ser necessário implementar mecanismos para suspender a atividade de gravação nos sistemas de arquivos de destino durante a criação desses snapshots.
Replicação
Dependendo da sua solução de armazenamento compartilhado e dos objetivos do ponto de recuperação, é possível replicar seus sistemas de arquivos. A replicação pode ser usada para bancos de dados, armazenamento em nível de bloco ou arquivos.
Projetar uma solução de DR que usa replicação é melhor para aplicativos essenciais que têm uma tolerância muito baixa à perda de dados.
Se o sistema principal é executado no Google Cloud, os buckets multirregionais e os snapshots multirregionais são replicados para você entre as regiões selecionadas.
Para a replicação de armazenamento no nível de bloco, use Replicação assíncrona de DP. A replicação assíncrona do DP fornece replicação assíncrona de objetivo de ponto de recuperação (RPO, na sigla em inglês) e baixo objetivo de tempo de recuperação (RTO, na sigla em inglês) para recuperação de desastres ativa e passiva entre regiões.
Também é possível usar a replicação fornecida por soluções de armazenamento de terceiros.
Armazenamento
Ao projetar uma solução de DR no Google Cloud, é provável que você use vários tipos de armazenamento, dependendo de onde seu sistema principal está sendo executado e do que ele armazena.
Buckets do Cloud Storage para arquivos de backup
Para backups que não sejam snapshots de disco, como arquivos enviados de um sistema SAP que não estejam sendo executados no Google Cloud, crie um bucket no Cloud Storage, que pode ser acessado pelo local principal e pelo local de DR. Ao criar um bucket, você escolhe uma classe de armazenamento padrão e um local.
Selecione uma classe de armazenamento padrão com base no contrato de nível de serviço (SLA, na sigla em inglês) necessário, no uso esperado do armazenamento e nas restrições de custo. Para DR, a classe de Coldline Storage geralmente é uma boa opção.
Para o local do bucket, escolha uma localização que inclua a região do seu local de DR e, se o sistema principal é executado no Google Cloud, a região do local principal.
Se o sistema principal estiver no Google Cloud, escolha um local multirregional que inclua as regiões do local principal e do local de DR, para que seja possível acessar o bucket dos dois locais.
Se o sistema principal não estiver no Google Cloud, para economizar custos, selecione só um local de região que esteja dentro da região do seu local de DR.
Se o sistema principal estiver no Google Cloud e você estiver usando uma solução de terceiros para armazenamento compartilhado, suas opções de armazenamento podem ser determinadas pela solução. Consulte a documentação da solução ou o representante do Cloud Customer Care.
Para informações sobre preços, consulte Preços do Cloud Storage.
Armazenamento para snapshots de disco permanente do Compute Engine
Ao criar um snapshot, é possível especificar um local de armazenamento. A localização de um snapshot afeta a disponibilidade dele e pode gerar custos de rede quando você o cria ou o restaura em um novo disco.
Os snapshots podem ser armazenados em qualquer local multirregional do Cloud Storage, como asia ou um local regional do Cloud Storage, como asia-south1.
Um local de armazenamento multirregional oferece maior disponibilidade e pode reduzir os custos de rede ao criar ou restaurar um snapshot. Um local de armazenamento regional oferece mais controle sobre o local físico dos seus dados.
Independentemente das opções de local escolhidas, os snapshots precisam ser armazenados em um local acessível a partir do local de DR.
Para mais informações sobre locais de snapshots, consulte Como selecionar o local de armazenamento para um snapshot.
Para informações sobre preços para armazenamento de snapshots, consulte Preços de disco permanente.
Armazenamento para imagens personalizadas
Depois de adicionar arquivos à sua lista de imagens personalizadas, o Compute Engine gerencia o armazenamento das imagens. As imagens em uma lista desse tipo são recursos globais, portanto estão disponíveis em qualquer região.
Para informações sobre preços de armazenamento de imagens, consulte Armazenamento de imagens.
Como testar seu plano de DR
Após a conclusão do seu plano de DR, teste-o regularmente, observando os problemas que surgirem e ajustando seu plano conforme necessário.
Não deixe de testar todos os aspectos do seu plano de DR, incluindo estes:
- Backups e agendamentos de backup
- Transferência de dados de locais fora da plataforma
- Recuperação dos backups armazenados
- Controles de segurança e acesso ao sistema
- Roteamento de rede
Ao testar seus sistemas de DR, seus sistemas principais continuarão em execução. Para evitar conflitos ou cenários de "dupla personalidade", é preciso isolar o sistema de teste do sistema primário e dos usuários dele.
Para informações gerais sobre o teste de DR no Google Cloud, consulte o Guia de planejamento de recuperação de desastres.
Como planejar sua solução de DR para atender aos seus RPOs e RTOs
Certos produtos, funções e serviços do Google Cloud são essenciais para projetar uma solução de DR que atenda aos seus RPOs e RTOs.
Como projetar para RPO
Ao projetar uma solução de DR no Google Cloud para atender a um RPO específico, há duas variáveis que controlam o momento para onde é possível se recuperar:
- Frequência de backup
- Retenção de backup
Frequência de backup
A frequência de backup determina o tempo máximo que pode decorrer entre seu último backup e um desastre. Se você criar seus backups de DR a cada 24 horas, poderá perder quase 24 horas em atualizações de dados se ocorrer um desastre 23 horas e 59 minutos após a realização do último backup.
A replicação pode reduzir o tempo máximo decorrido desde o último backup para quase zero. A replicação, no entanto, é cara. Por isso, é possível usá-la apenas para bancos de dados e arquivos de aplicativos essenciais.
Em uma solução de DR, cópias ou snapshots pontuais são comumente usados para fazer backup dos sistemas de arquivos de aplicativos SAP necessários para recuperação.
No Google Cloud, é possível automatizar snapshots de discos permanentes do Compute Engine criando uma programação de snapshots por hora, dia ou semana. No entanto, como os snapshots do Compute Engine controlam a consistência apenas no nível do bloco, considere suspender a atividade de gravação nos sistemas de arquivos de destino durante a criação de snapshots para garantir a consistência no nível do arquivo.
O principal custo a considerar ao escolher uma frequência de backup é o da transferência de dados. O custo de armazenamento também é algo a se levar em consideração, mas sua política de retenção de backup pode ter um impacto maior nos custos de armazenamento do que sua frequência de backup.
Para mais informações sobre agendamentos de snapshots, consulte Como criar snapshots agendados para discos permanentes.
Retenção de backup
A retenção de backup determina em quanto tempo é possível mover seu ponto de recuperação. A retenção de cópias de backup ajuda a proteger contra erros lógicos, permitindo que você se recupere até um ponto no tempo antes que o erro lógico exista.
É possível definir políticas de retenção para snapshots do Compute Engine e buckets do Cloud Storage que excluem automaticamente seus arquivos de backup após um período especificado.
O principal custo a considerar ao escolher uma política de retenção é o de armazenamento. Os snapshots do Compute Engine reduzem a quantidade de armazenamento necessária para vários snapshots, armazenando apenas alterações incrementais no nível do bloco depois que o primeiro snapshot completo é armazenado.
Para mais informações sobre como definir políticas de retenção para snapshots, consulte Política de retenção de snapshots.
Para informações sobre como definir políticas de retenção nos buckets do Cloud Storage, consulte Políticas de retenção usando bloqueio de bucket.
Como projetar para RTO
Ao projetar sua solução de DR do Google Cloud para atender a um RTO específico, a prontidão da infraestrutura, software, sistemas de arquivos e dados no local de DR é a variável de controle principal.
Por exemplo, para ter um RTO muito baixo, é possível manter um sistema de espera ativa no local de DR, com infraestrutura pré-implementada, sistemas SAP ativos e dados replicados. No entanto, o baixo RTO tem um custo mais alto.
É possível equilibrar custos e tempos de recuperação, configurando antecipadamente alguma infraestrutura de baixo ou nenhum custo e adiando algumas etapas de configuração para o momento da recuperação.
Por exemplo, é possível configurar e implantar uma VM com antecedência, mas em seguida pará-la. Os recursos conectados à VM, como IPs estáticos externos ou discos permanentes, ainda podem gerar cobranças, mas a própria VM parada não.
Como é possível configurar e implantar uma VM do Compute Engine no Google Cloud relativamente rápido, faça isso no momento da recuperação e você ainda atenderá ao RTO, especialmente se usar o Terraform ou o Deployment Manager para implantar o sistema de DR ou criar a VM a partir de um modelo e uma imagem personalizada criados com antecedência.
Considerações de cota e recursos para soluções de DR de alto RTO
Se você não pré-implantar sua infraestrutura e sistemas, verifique periodicamente suas cotas de recursos na região do local de DR para garantir que elas sejam suficientes para implantar o sistema de DR.
A pré-implantação de toda a infraestrutura e dos sistemas de DR permitidos pelo seu orçamento pode ajudar a garantir que seu sistema de DR se enquadre nas cotas e que os recursos do Google Cloud necessários ao sistema estejam disponíveis quando ele precisar.
Arquiteturas de exemplo para diferentes objetivos
Os diagramas de arquitetura a seguir mostram exemplos de projetos de DR para diferentes RTOs.
Cada um dos diagramas mostra opções de backup de várias regiões à esquerda e uma configuração SAP simplificada correspondente no local de DR à direita.
Cada exemplo mostra uma combinação possível de elementos de design de DR. Para ajustar seu design de DR aos objetivos e circunstâncias, combine elementos de um ou de todos os exemplos.
Exemplo de arquitetura de DR de baixo RTO
O diagrama da arquitetura a seguir mostra um exemplo de design de DR de baixo RTO.
Nesse design, você mantém um sistema SAP quase funcional no local do DR. As VMs são implantadas e ficam ativas. Os servidores de aplicativos SAP e o servidor de banco de dados estão ativos, mas o serviço de aplicativo está parado.
As opções de backup que você provavelmente usará neste cenário incluem imagens de SO e snapshots de discos permanentes armazenados no Compute Engine, além de replicação de dados entre os sites principal e de DR. Para a replicação de dados, use Replicação assíncrona de DP.
Como a replicação de dados é usada, o risco de perda de dados é limitado à última sincronização do banco de dados.
Para estender seu RPO de volta no tempo, é possível adicionar backups de dados ao Cloud Storage, o que não é mostrado no diagrama. Para os snapshots de discos permanentes, use snapshots agendados e ajuste a política de retenção ao seu RPO.
Veja as ações que você precisa executar para recuperar um sistema com baixo RTO como este:
- Se necessário, execute uma sincronização final dos arquivos ou recupere-os com um snapshot de disco permanente.
- Altere o banco de dados principal para o local de DR.
- Inicie o aplicativo no local de DR.
Das três arquiteturas de exemplo mostradas, o exemplo de baixo RTO é o mais caro.
Exemplo de arquitetura de DR de médio RTO
O exemplo a seguir da arquitetura de DR tem um RTO mais alto que o exemplo anterior, mas um custo mais baixo.
Nesse design, o servidor de banco de dados está ativo para oferecer suporte à replicação do local principal. As VMs para os servidores de aplicativos não estão ativas.
As opções de backup que você provavelmente usará neste cenário incluem imagens de SO e snapshots de discos permanentes armazenados no Compute Engine, além de replicação de dados entre os sites principal e de DR. Para a replicação de dados, use Replicação assíncrona de DP.
Como a replicação de dados é usada, o risco de perda de dados é limitado à última sincronização do banco de dados.
Para estender seu RPO de volta no tempo, é possível armazenar backups de dados em um bucket do Cloud Storage, o que não é mostrado no diagrama. Para os snapshots de discos permanentes, use snapshots agendados e ajuste a política de retenção ao seu RPO.
Dependendo dos requisitos do seu sistema de banco de dados, é possível implantar seu banco de dados em uma VM menor no local de DR do que o necessário no local principal, o que pode ajudar a reduzir custos até que o sistema de DR seja ativado. Nesse caso, você precisa redimensionar a VM para o tamanho necessário durante a recuperação.
Veja as ações que você precisa executar para recuperar um sistema como este:
- Se necessário, implante as instâncias da VM para SAP NetWeaver e os servidores de aplicativos a partir de snapshots ou imagens de discos permanentes.
- Sincronize os sistemas de arquivos a partir de snapshots de discos permanentes ou outro armazenamento.
- Se necessário, redimensione a instância da VM do banco de dados.
- Altere o banco de dados principal para o local de DR.
- Inicie o serviço de aplicativo no local de DR.
Exemplo de arquitetura de DR de alto RTO
O diagrama da arquitetura a seguir tem o RTO mais alto dos exemplos mostrados e é a opção de menor custo.
Nesse design, é possível pré-implantar os servidores e pará-los para evitar cobranças pelas VMs ou, para evitar custos associados a discos permanentes e outros recursos relacionados à VM, implantar as VMs como parte do seu processo de recuperação.
As opções de backup que você provavelmente usa neste cenário incluem imagens de SO e snapshots de discos permanentes armazenados no Compute Engine, além de backups de dados armazenados no Cloud Storage.
Para atender ao seu RPO, ajuste a frequência de backup e as políticas de retenção dos agendamentos de snapshots e dos backups no bucket do Cloud Storage.
Veja as ações que você precisa executar para recuperar um sistema como este:
- Se necessário, implante as instâncias da VM para SAP NetWeaver, os servidores de aplicativos e o servidor de banco de dados a partir de snapshots ou imagens de discos permanentes multirregionais armazenados no Compute Engine.
- Sincronize os sistemas de arquivos a partir de snapshots de discos permanentes ou outro armazenamento.
- Recupere o banco de dados de arquivos de backup no bucket multirregional do Cloud Storage ou em outro local.
- Altere o banco de dados principal para o local de DR.
- Inicie o serviço de aplicativo no local de DR.
Parceiros e produtos para soluções de DR para SAP no Google Cloud
Encontre parceiros para ajudar com sua solução de DR no diretório de parceiros do Google Cloud.
Também é possível encontrar vários produtos e parceiros de suporte para sua solução de DR no Google Cloud Marketplace.