O Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR) orquestra a transição de computação, banco de dados e aplicações entre regiões da OCI de todo o mundo com um único clique. Os clientes podem automatizar as etapas necessárias para recuperar um ou mais sistemas de negócios sem redesenhar ou reprojetar infraestrutura, bancos de dados ou aplicações existentes e sem precisar de servidores especializados de gerenciamento ou conversão.
O OCI Full Stack DR está disponível nas regiões comerciais da OCI, regiões governamentais do Reino Unido, regiões soberanas da UE, regiões do Oracle Alloy e OCI Dedicated Regions. Para obter uma lista abrangente de disponibilidade de serviços, consulte a página de disponibilidade de regiões do Full Stack DR. O processo de integração para as regiões Oracle US Government Cloud e Oracle US Defense Cloud ainda está em andamento. Para obter mais informações sobre as regiões da OCI, incluindo domínios e suas localizações específicas, consulte a documentação de domínios e regiões da OCI.
No momento, o OCI Full Stack Disaster Recovery atende aos recursos disponíveis nas regiões da OCI, e os recursos devem estar na mesma tenancy. O Full Stack DR oferece suporte ao Oracle Database@Azure, o que significa que as transições de atribuição no nível do banco de dados só podem ser tratadas usando o Full Stack DR. No entanto, é importante observar que a capacidade de oferecer suporte à recuperação de desastres em estratégias on-premises, híbridas e multicloud faz parte do roadmap para o desenvolvimento futuro. A Oracle planeja estender a funcionalidade do OCI Full Stack DR para abranger esses ambientes, permitindo que você tenha uma solução de recuperação de desastres que cubra uma variedade mais ampla de cenários.
Não. A recuperação de desastres na OCI requer que todos os serviços da OCI suportem operações entre tenancies. Pouquíssimos serviços da OCI oferecem suporte à replicação ou ao controle entre tenancies. Como o Full Stack DR depende dos recursos e das APIs fornecidos por todos os serviços da OCI, o Full Stack DR não pode fornecer orquestração de recuperação até que todos os serviços da OCI ofereçam suporte a recursos entre tenancies.
Sim, pode. A implementação de recursos da OCI em duas regiões fornece recursos aprimorados de recuperação de desastres. Essa abordagem ajuda a garantir alta disponibilidade e resiliência para aplicações e serviços críticos. No caso de um desastre ou interrupção em uma região, os recursos podem fazer failover para a outra região, reduzindo o tempo de inatividade e minimizando o impacto nas operações comerciais. Ao distribuir recursos em diversas regiões, você pode obter uma estratégia robusta de recuperação de desastres que oferece maior proteção de dados e continuidade dos negócios.
Não, o OCI Full Stack DR é um serviço totalmente gerenciado.
Sim, o OCI Full Stack DR fornece SLAs de disponibilidade e desempenho. Para saber mais, consulte o Documento do Pilar Oracle PaaS and IaaS Public Cloud Services (PDF).
Você pode acessar o OCI Full Stack DR usando o console da Oracle Cloud Infrastructure (uma interface baseada em navegador), APIs REST, SDKs da Oracle Cloud Infrastructure, uma interface de linha de comando e de ferramentas DevOps.
Sim, o OCI Full Stack DR pode ser usado para cargas de trabalho Oracle e não Oracle.
Não. Por design, o Full Stack DR permite que você crie planos de recuperação de desastres apenas na região do grupo de proteção em espera. É altamente recomendável usar uma execução de teste de um plano de switchover para criar todos os planos de recuperação de desastres (planos de switchover, failover e drill) no outro grupo de proteção de recuperação de desastres. Isso garantirá que os planos de recuperação de desastres estejam disponíveis em ambas as regiões.
Depende dos requisitos da aplicação. Se não houver dependências de aplicações (por exemplo, se várias alternâncias de banco de dados puderem ocorrer em paralelo com a recuperação do servidor de aplicações), o ideal seria ter vários grupos de proteção de recuperação de desastres. Isso também ajudaria a melhorar o objetivo geral de tempo de recuperação da aplicação de negócios. No entanto, se as etapas de recuperação dependerem umas das outras, seria interessante ter um plano de recuperação em um único grupo de proteção de recuperação de desastres. O Full Stack DR é altamente flexível; você pode criar grupos de proteção de recuperação de desastres e planos de recuperação de desastres, de acordo com suas necessidades.
O OCI Full Stack DR ajuda a automatizar as etapas de recuperação de aplicações existentes. Para integrar com Full Stack DR, você precisará concluir o seguinte:
Sim, o Full Stack DR é um serviço altamente flexível. Você pode integrar qualquer implementação de recuperação de desastres com o OCI Full Stack Disaster Recovery.
Você precisará configurar toda a infraestrutura de produção/recuperação de desastres e componentes de aplicações. Dependendo das implementações de recuperação de desastres, isso pode incluir o seguinte:
Você pode adicionar os seguintes tipos de recursos como membros do grupo de proteção de recuperação de desastres.
Ao criar o plano de RD, o OCI Full Stack Disaster Recovery gera automaticamente grupos de planos integrados. Seu plano de RD pode ser ainda mais personalizado para interagir com quaisquer outros serviços da OCI por meio de grupos de planos definidos pelo usuário usando scripts ou Oracle Cloud Infrastructure Functions.
Existem quatro tipos de planos de RD.
Sim, temos planos de adicionar outros serviços principais da OCI, como o OCI Kubernetes Engine (OKE). Verifique novamente se há mais informações.
Sim. O OCI Full Stack DR depende das APIs do Oracle Database PaaS Data Guard para gerar grupos de planos para alternância ou failover para o banco de dados. Mas, dito isso, você pode usar scripts personalizados para controlar as alterações de função do Oracle Data Guard nos casos em que o Data Guard foi configurado manualmente.
Sim, supondo que você tenha o Oracle Data Guard configurado para os bancos de dados em execução em uma VM da OCI. Você pode criar grupos de planos definidos pelo usuário e usar o broker do Data Guard ou scripts de reversão de função.
Recomendamos que você siga as tecnologias nativas para replicar os bancos de dados de produção e stand-by. Você pode usar grupos de planos definidos pelo usuário e trazer seus próprios scripts para executar a reversão de função de banco de dados.
Instância móvel: normalmente usado em topologias de recuperação de desastres de VM piloto leve ou fria, em que as instâncias que compõem a pilha de aplicações são implementadas apenas na região primária. As instâncias são movidas do grupo de proteção de RD primário para o grupo de proteção de RD stand-by.
Instância não móvel: normalmente usada para topologias de DR ativa-passiva em que as instâncias que compõem a pilha de aplicações são pré-implementadas em regiões e componentes de software de aplicação. Você inicia ou interrompe essas instâncias durante as operações de RD para fazer a transição do serviço de uma região para outra.
Se você adicionou uma instância de computação móvel ou imóvel como membro do grupo de proteção de RD primário, deverá adicionar o grupo de volume de inicialização/bloco relevante como membro desse grupo primário.
É possível especificar os detalhes da opção de montagem do volume em blocos nas propriedades do membro da instância imóvel. Você deve adicionar o grupo de volumes em blocos relevante como membro do grupo de proteção de RD primário.
Não, você não pode adicionar esses bancos de dados como tipos de membro com o Full Stack DR. Depois que os recursos nativos de replicação entre regiões forem disponibilizados pelo serviço apropriado, a equipe do Full Stack DR planeja oferecer suporte a esses serviços como tipos de membros. Hoje, os clientes podem usar scripts personalizados e integrá-los ao Full Stack DR se o processo de recuperação dos bancos de dados puder ser concluído. Por exemplo, o HeatWave MySQL oferece suporte a recursos de backup e restauração entre regiões; se o processo de recuperação puder ser programado, eles poderão ser adicionados ao plano de DR usando os grupos de planos definidos pelo usuário.
Objetivo de tempo de recuperação (Recovery Time Objective, RTO): RTO é o prazo dentro do qual uma determinada aplicação ou sistema devem ser totalmente restaurados e operacionais após um desastre ou evento interruptivo. Representa o tempo de inatividade máximo permitido que a empresa pode tolerar para essa aplicação. Em outras palavras, indica a rapidez com que a aplicação precisa estar operacional novamente para atender aos requisitos de continuidade dos negócios. As aplicações críticas geralmente têm um RTO baixo, pois precisam ser restauradas rapidamente para minimizar interrupções e manter as operações essenciais.
Objetivo de ponto de recuperação (Recovery Point Objective, RPO): O RPO refere-se à perda máxima de dados tolerável em caso de desastre ou interrupção. Representa o período de tempo durante o qual dados podem ser perdidos (sem backup ou replicação) antes que o desastre comece a impactar significativamente os negócios. Por exemplo, se uma aplicação tiver um RPO de uma hora, isso significa que, após um desastre, os dados deverão ser recuperados até um ponto não superior a uma hora antes da ocorrência do incidente. Aplicações com um RPO mais baixo normalmente exigem backups ou replicações mais frequentes para garantir perda mínima de dados.
Tanto o RTO como o RPO são considerações essenciais no planejamento de recuperação de desastres, uma vez que impactam diretamente a continuidade e a resiliência das operações empresariais durante e após um evento disruptivo. As organizações precisam equilibrar esses objetivos com base na criticidade das suas aplicações e no custo de implementação das medidas de RD necessárias.
O RTO de uma aplicação pode ser determinado considerando o tempo necessário para concluir o plano de transição ou failover. O OCI Full Stack DR, com seu processo de recuperação totalmente automatizado, pode melhorar significativamente o RTO, minimizando o tempo de inatividade e reduzindo a intervenção manual necessária para a recuperação.
Ao automatizar os processos de failover e alternância, o OCI Full Stack DR simplifica o fluxo de trabalho de recuperação e permite que as aplicações sejam colocadas online rapidamente. Essa redução no tempo de recuperação pode levar a uma melhor continuidade dos negócios e à redução de interrupções durante um desastre.
O OCI Full Stack DR não tem controle do RPO, pois ele pode variar com base nos serviços da OCI, seus métodos de replicação e configurações. Diferentes serviços dentro da Oracle Cloud Infrastructure podem ter diretrizes específicas de RPO, dependendo de como eles lidam com a replicação e a sincronização de dados.
Por exemplo, para o Oracle Autonomous Database Serverless, a Oracle pode ter publicado valores de RPO para bancos de dados stand-by entre regiões, indicando a perda de dados máxima tolerável para essa configuração específica.
Para garantir a conformidade com o RPO desejado e entender os recursos de recuperação de dados de cada serviço da OCI, consulte a documentação do respectivo serviço. Essas diretrizes fornecem informações detalhadas sobre como os dados são replicados, quais opções de recuperação estão disponíveis e o RPO esperado para diferentes configurações. Seguindo as recomendações da documentação, você pode implementar uma estratégia de recuperação de desastres adequada que se alinhe às necessidades do seu negócio e aos requisitos de proteção de dados.
O preço do OCI Full Stack DR segue o modelo de preços de OCPU e ECPU por hora da OCI. O preço do serviço é baseado na contagem de CPU (OCPU e ECPU) de cada tipo de membro adicionado a um grupo de proteção de RD. Ele usa apenas as CPUs alocadas para calcular as cobranças. Armazenamento, rede e outros usos de recursos que fazem parte dos grupos de proteção Full Stack DR não são cobrados pelo Full Stack DR.
Para saber mais, consulte o estimador de custos da OCI e a lista de preços da OCI (PDF).
O preço do OCI Full Stack DR é baseado no número de OCPUs e ECPUs de recursos de computação e de banco de dados adicionados como membros nos grupos de proteção de RD primário e standby.
Exemplo 1
Exemplo 2
Observe que o preço por hora e o modelo podem mudar no futuro. Para saber os preços atuais, consulte as diretrizes de preços mais recentes ou entre em contato com seu representante de vendas da Oracle.
Não, não há preços separados para adicionar um grupo de volumes como membro de um grupo de proteção de RD. O preço do OCI Full Stack DR só é aplicável a tipos de membros de computação e banco de dados. O Full Stack DR não cobra a mais pelos seguintes tipos de recursos da OCI:
Sim. Você pagará os custos normais dos serviços da OCI necessários para implementar a pilha de aplicações, independentemente de estar usando o Full Stack DR ou não. Você pagará pelo OCI Networking, OCI Compute, consumo de armazenamento da OCI, OCI Load Balancer, bancos de dados Oracle e quaisquer outros serviços da OCI que sua pilha de aplicações exigir. O custo do Full Stack DR é um custo adicional baseado no número de ECPUs e OCPUs, conforme explicado na resposta à pergunta 2 desta seção.
O custo associado aos serviços da OCI e a um modelo de implementação de RD variará dependendo dos serviços e configurações específicos que você escolher. Por exemplo, se você optar pela replicação em bloco entre regiões, haverá um custo adicional de armazenamento. Da mesma forma, a utilização de uma base de dados stand-by autônoma também implicará em despesas adicionais. Para saber mais sobre os preços de cada serviço da OCI, consulte os detalhes de preços da Oracle Cloud Infrastructure.