Projeto para backup e recuperação
Organizações, como a Tailwind Traders, exigem um alto grau de confiabilidade de seus aplicativos de missão crítica. Para obter a confiabilidade desejada para aplicativos locais, é comum comprar mais recursos de computação, como servidores e armazenamento. A compra de mais recursos de computação cria redundância em uma infraestrutura local.
Também é vital que qualquer aplicativo de missão crítica e seus dados associados sejam recuperáveis após uma falha, idealmente até o ponto de falha. Essa capacidade de recuperação geralmente é fornecida por backup, componentes de restauração e procedimentos. Para organizações com aplicativos hospedados no Azure ou organizações com implantações de aplicativos híbridos, há outras considerações e opções.
As aplicações fiáveis são:
Resiliente a falhas de componentes.
Altamente disponível e pode ser executado em um estado saudável sem tempo de inatividade significativo.
Para alcançar a resiliência desejada e a alta disponibilidade, você deve primeiro definir seus requisitos.
Nota
Este módulo usará o termo resiliência como a capacidade de um sistema de lidar graciosamente e se recuperar de falhas, tanto inadvertidas quanto maliciosas.
Definir as condições necessárias
A definição dos seus requisitos envolve:
Identificar as necessidades do seu negócio.
Construindo seu plano de resiliência para atender a essas necessidades.
Use a tabela de considerações a seguir para fornecer orientação sobre esse processo.
Consideração | Descrição |
---|---|
Quais são suas cargas de trabalho e seu uso? | Uma carga de trabalho é uma capacidade ou tarefa discreta que é logicamente separada de outras tarefas, em termos de lógica de negócio e requisitos de armazenamento de dados. Cada carga de trabalho provavelmente tem requisitos diferentes de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres. |
Quais são os padrões de uso para suas cargas de trabalho? | Os padrões de utilização podem determinar os seus requisitos. Identificar diferenças nos requisitos durante períodos críticos e não críticos. Para garantir o tempo de atividade, planeje redundância em várias regiões caso uma delas falhe. Por outro lado, para minimizar os custos durante períodos não críticos, você pode executar seu aplicativo em uma única região. |
Quais são as métricas de disponibilidade? | O tempo médio de recuperação (MTTR) e o tempo médio entre falhas (MTBF) são as métricas normalmente usadas. O MTBF é o tempo durante o qual um componente pode esperar razoavelmente entre falhas. O MTTR é o tempo médio necessário para restaurar um componente após uma falha. Use essas métricas para determinar onde você precisa adicionar redundância e para determinar contratos de nível de serviço (SLAs) para clientes. |
Quais são as métricas de recuperação? | O RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é o tempo máximo aceitável em que um dos seus aplicativos pode ficar indisponível após um incidente. O RPO (Recovery Point Objetive, objetivo de ponto de recuperação) é a duração máxima da perda de dados aceitável durante um desastre. Considere também o objetivo de nível de recuperação (RLO). Essa métrica determina a granularidade da recuperação. Em outras palavras, se você deve ser capaz de recuperar um farm de servidores, um aplicativo Web, um site ou apenas um item específico. Para determinar esses valores, realize uma avaliação de risco. Certifique-se de entender o custo e o risco de tempo de inatividade ou perda de dados em sua organização. |
Quais são as metas de disponibilidade da carga de trabalho? | Para ajudar a garantir que a arquitetura do seu aplicativo atenda aos seus requisitos de negócios, defina SLAs de destino para cada carga de trabalho. Conte com o custo e a complexidade do cumprimento dos requisitos de disponibilidade, além das dependências de aplicações. |
Quais são seus SLAs? | No Azure, o SLA descreve os compromissos da Microsoft quanto ao período de disponibilidade e à conectividade. Se o SLA para um determinado serviço for 99,9%, significa que o serviço deve estar disponível 99,9% do tempo. |
Gorjeta
Se o MTTR de qualquer componente crítico em um cenário altamente disponível exceder o RTO do sistema, uma falha no sistema pode causar uma interrupção de negócios inaceitável. Em outras palavras, você não pode restaurar o sistema dentro do RTO definido.
Defina seus próprios SLAs de destino para cada carga de trabalho em sua solução respondendo às perguntas anteriores. Isso ajuda a garantir que a arquitetura atenda aos seus requisitos de negócios. Por exemplo, se uma carga de trabalho requer 99,99% de tempo de atividade, mas depende de um serviço com um SLA de 99,9%, esse serviço não pode ser um único ponto de falha no sistema.
Depois de definir os requisitos de recuperação, você pode selecionar uma tecnologia de recuperação adequada.