Continuidade de negócios e recuperação de desastres para análises em escala de nuvem
Ao projetar a arquitetura para um serviço de nuvem, considere seus requisitos de disponibilidade e como responder a possíveis interrupções no serviço. Um problema pode ser restrito a uma instância específica ou a toda a região. Ter planos para ambos é importante. Dependendo do seu objetivo de tempo de recuperação e do objetivo do ponto de recuperação, você pode escolher uma estratégia agressiva para alta disponibilidade e recuperação de desastres.
Às vezes, a alta disponibilidade e a recuperação de desastres podem ser combinadas. As duas áreas têm estratégias ligeiramente diferentes, especialmente quando se trata de dados. Para saber mais, consulte o Microsoft Azure Well-Architected Framework e seus princípios de confiabilidade .
Em vez de tentar evitar falhas, aceite antecipadamente que as falhas podem e acontecem. Minimize os efeitos de qualquer componente com falha no ciclo de vida. Sua tolerância de custo, objetivo de ponto de recuperação e objetivo de tempo de recuperação determinam o tipo de solução a ser implementada.
Estratégias de backup
Muitas estratégias alternativas estão disponíveis para implementar computação distribuída entre regiões. As estratégias devem ser adaptadas aos requisitos de negócios e às circunstâncias do seu aplicativo. A um nível elevado, as abordagens enquadram-se nas seguintes categorias:
Backup e restauração: Restaure o aplicativo de banco de dados a partir da última cópia de backup antes do desastre. Essa abordagem é comumente usada após corrupção de dados ou exclusão acidental.
Reimplantar em caso de desastre: Reimplante a aplicação do zero quando ocorrer um desastre. Essa abordagem é apropriada para aplicativos não críticos que não exigem um tempo de recuperação garantido.
Sobressalente quente (ativo/passivo): Crie um serviço hospedado secundário em uma região alternativa. Implante funções para garantir capacidade mínima. As funções não recebem tráfego de produção. Essa abordagem é útil para aplicativos que não foram projetados para distribuir tráfego entre regiões.
Hot spare (ativo/ativo): Projete o aplicativo para receber carga de produção em várias regiões. Você pode configurar os serviços de nuvem em cada região para uma capacidade maior do que a necessária para fins de recuperação de desastres. Em vez disso, você pode expandir os serviços de nuvem conforme necessário no momento de um desastre e failover.
Essa abordagem requer investimento no design de aplicativos, mas tem benefícios. Oferece um tempo de recuperação baixo e garantido. Há testes contínuos de todos os locais de recuperação e uso eficiente da capacidade. Para aplicativos de banco de dados, essa abordagem inclui um balanceador de carga para dois bancos de dados que sincronizam com um único ponto de conexão.
Recuperação de desastres e alta disponibilidade para serviços do Azure
O Cloud Scale Analytics é composto por vários serviços do Azure que são agrupados em plataforma, núcleo e dados. Para obter mais informações sobre guias de confiabilidade específicos do serviço e recuperação de desastres, consulte documentação de confiabilidade do Azure