Partilhar via

Documentação de fiabilidade do Azure

  • Artigo

A fiabilidade consiste em dois princípios: resiliência e disponibilidade. O objetivo da resiliência é evitar falhas e, se elas ainda ocorrerem, retornar seu aplicativo a um estado totalmente funcional. O objetivo da disponibilidade é fornecer acesso consistente ao seu aplicativo ou carga de trabalho. É importante planejar a confiabilidade proativa com base nos requisitos do seu aplicativo.

O Azure inclui serviços de fiabilidade incorporados que pode utilizar e gerir com base nas suas necessidades empresariais. Quer se trate de uma falha de nó de hardware único, uma falha ao nível do rack, uma interrupção do centro de dados ou uma interrupção regional em grande escala, o Azure fornece soluções que melhoram a fiabilidade. Por exemplo, os conjuntos de disponibilidade garantem que as máquinas virtuais implantadas no Azure sejam distribuídas entre vários nós de hardware isolados em um cluster. As zonas de disponibilidade protegem os aplicativos e os dados dos clientes contra falhas no datacenter em vários locais físicos dentro de uma região. As regiões e as zonas de disponibilidade são fundamentais para o design do aplicativo e a estratégia de resiliência e são discutidas com mais detalhes mais adiante neste artigo.

A documentação de confiabilidade do Azure oferece orientação de confiabilidade para os serviços do Azure. Essas diretrizes incluem informações sobre suporte à zona de disponibilidade, orientação de recuperação de desastres e disponibilidade de serviços.

Para obter orientações detalhadas de confiabilidade específicas do serviço, incluindo zonas de disponibilidade, recuperação de desastres ou alta disponibilidade, consulte Visão geral das diretrizes de confiabilidade específicas do serviço do Azure.

Para obter informações sobre princípios e arquitetura de confiabilidade e confiabilidade nos serviços do Microsoft Azure, consulte Microsoft Azure Well-Architected Framework: Confiabilidade.

Requisitos de fiabilidade

O nível necessário de confiabilidade para qualquer solução do Azure depende de várias considerações. O SLA de disponibilidade e latência e outros requisitos de negócios orientam as escolhas arquitetônicas e o nível de resiliência e devem ser considerados primeiro. Os requisitos de disponibilidade variam desde quanto tempo de inatividade é aceitável – e quanto custa à sua empresa – até a quantidade de dinheiro e tempo que você pode investir realisticamente para tornar um aplicativo altamente disponível.

Criar sistemas de fiabilidade no Azure é uma responsabilidade partilhada. A Microsoft é responsável pela fiabilidade da plataforma na nuvem, incluindo a sua rede global e centros de dados. Os clientes e parceiros do Azure são responsáveis pela resiliência das suas aplicações na nuvem, utilizando as melhores práticas de arquitetura com base nos requisitos de cada carga de trabalho. Enquanto o Azure se esforça continuamente para obter a maior resiliência possível no SLA para a plataforma de nuvem, você deve definir seus próprios SLAs de destino para cada carga de trabalho em sua solução. Um SLA permite avaliar se a arquitetura cumpre os requisitos comerciais. À medida que você se esforça por maiores porcentagens de tempo de atividade garantido por SLA, o custo e a complexidade para atingir esse nível de disponibilidade aumentam. Um tempo de atividade de 99,99% se traduz em cerca de cinco minutos de tempo total de inatividade por mês. Vale a pena mais complexidade e custo para atingir essa percentagem? A resposta depende dos requisitos individuais do negócio. Ao decidir os compromissos finais de SLA, entenda os SLAs suportados pela Microsoft. Cada serviço do Azure tem seu próprio SLA.

Diagram showing the shared responsibility model for Azure business continuity.

No modelo on-premises tradicional, toda a responsabilidade de gerenciar, desde o hardware para computação, armazenamento e rede até o aplicativo, recai sobre você. Você deve planejar vários tipos de falhas e como lidar com elas criando uma estratégia de recuperação de desastres. Com a IaaS, o provedor de serviços de nuvem é responsável pela resiliência da infraestrutura principal, incluindo armazenamento, rede e computação. À medida que você passa de IaaS para PaaS e, em seguida, para SaaS, você descobrirá que é responsável por menos e o provedor de serviços de nuvem é responsável por mais.  

Para obter mais informações sobre os princípios de confiabilidade, consulte a documentação de confiabilidade da estrutura bem arquitetada.  

Fiabilidade do edifício

Você deve definir os requisitos de confiabilidade do seu aplicativo no início do planejamento. Se você souber quais aplicativos não precisam de 100% de alta disponibilidade durante determinados períodos de tempo, poderá otimizar os custos durante esses períodos não críticos. Identifique o tipo de falhas que um aplicativo pode enfrentar e o efeito potencial de cada falha. Um plano de recuperação deve abranger todos os serviços críticos, finalizando a estratégia de recuperação no componente individual e no nível geral do aplicativo. Projete sua estratégia de recuperação para proteger contra falhas zonais, regionais e no nível do aplicativo. Execute testes completos do ambiente de aplicativos para medir a confiabilidade e a recuperação do aplicativo contra falhas inesperadas.

A lista de verificação a seguir abrange o escopo do planejamento de confiabilidade.

Planeamento da fiabilidade
Defina metas de disponibilidade e recuperação para atender aos requisitos de negócios.
Projete os recursos de confiabilidade de seus aplicativos com base nos requisitos de disponibilidade.
Alinhe aplicativos e plataformas de dados para atender aos seus requisitos de confiabilidade.
Configure caminhos de conexão para promover a disponibilidade.
Use zonas de disponibilidade e planejamento de recuperação de desastres, quando aplicável, para melhorar a confiabilidade e otimizar os custos.
Certifique-se de que sua arquitetura de aplicativo seja resiliente a falhas.
Saiba o que acontece se os requisitos de SLA não forem cumpridos.
Identificar possíveis pontos de falha no sistema, o design do aplicativo deve tolerar falhas de dependência implantando disjuntores.
Crie aplicativos que operam na ausência de suas dependências.

RTO e RPO

Duas métricas importantes a considerar são o objetivo de tempo de recuperação e o objetivo de ponto de recuperação, uma vez que pertencem à recuperação após desastre.  Para obter mais informações sobre requisitos de projeto funcionais e não funcionais, consulte Requisitos funcionais e não funcionais do Framework bem arquitetado.

  • O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável que uma aplicação pode ficar indisponível após um incidente.

  • O objetivo de ponto de recuperação (RPO) é a duração máxima de perda de dados que é aceitável durante um desastre.

RTO e RPO são requisitos não funcionais de um sistema e devem ser ditados por requisitos de negócios. Para derivar estes valores, é recomendado realizar uma avaliação de risco e compreender claramente o custo de tempo de inatividade ou perda de dados.  

Regiões e zonas de disponibilidade

As regiões e as zonas de disponibilidade são uma grande parte da equação da fiabilidade. As regiões apresentam várias zonas de disponibilidade fisicamente separadas. Essas zonas de disponibilidade são conectadas por uma rede de alto desempenho com latência inferior a 2ms entre zonas físicas. A baixa latência ajuda seus dados a permanecerem sincronizados e acessíveis quando algo dá errado. Você pode usar essa infraestrutura estrategicamente enquanto arquiteta aplicativos e infraestrutura de dados que replicam e fornecem automaticamente serviços ininterruptos entre zonas e entre regiões.

Os serviços do Microsoft Azure suportam zonas de disponibilidade e estão habilitados para conduzir suas operações de nuvem com alta disponibilidade ideal e, ao mesmo tempo, dar suporte às suas necessidades de recuperação entre regiões e estratégia de continuidade de negócios.

Para o planejamento de recuperação de desastres, as regiões emparelhadas com outras regiões oferecem replicação entre regiões e fornecem proteção replicando dados de forma assíncrona em outras regiões do Azure. As regiões sem par seguem as diretrizes de residência de dados e oferecem alta disponibilidade com zonas de disponibilidade e armazenamento localmente redundante ou com redundância de zona. Os clientes precisarão planejar a recuperação de desastres entre regiões com base em suas necessidades de RTO/RPO.

Escolha a melhor região para suas necessidades com base em considerações técnicas e regulatórias — recursos de serviço, residência de dados, requisitos de conformidade, latência — e comece a avançar em sua estratégia de confiabilidade. Para obter mais informações, consulte Regiões do Azure e zonas de disponibilidade.

Dependências do serviço do Azure

Os serviços do Microsoft Azure estão disponíveis globalmente para impulsionar suas operações de nuvem em um nível ideal.

Os serviços do Azure implantados em regiões do Azure são listados na página de produtos de infraestrutura global do Azure. Para entender melhor as regiões e zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade no Azure.

Os serviços do Azure são criados para confiabilidade, incluindo alta disponibilidade e recuperação de desastres. Não há serviços que dependam de um único data center lógico (para evitar pontos únicos de falha). Os serviços não regionais listados nos produtos de infraestrutura global do Azure são serviços para os quais não há dependência em uma região específica do Azure. Os serviços não regionais são implantados em duas ou mais regiões e, se houver uma falha regional, a instância do serviço em outra região continua atendendo aos clientes. Certos serviços não regionais permitem que os clientes especifiquem a região onde a máquina virtual (VM) subjacente na qual o serviço é executado será implantada. Por exemplo, a Área de Trabalho Virtual do Azure permite que os clientes especifiquem o local da região onde a VM reside. Todos os serviços do Azure que armazenam dados do cliente permitem que o cliente especifique as regiões específicas nas quais seus dados serão armazenados. A exceção é o Microsoft Entra ID, que tem posicionamento geográfico (como Europa ou América do Norte). Para obter mais informações sobre residência de armazenamento de dados, consulte o Mapa de residência de dados.

Se precisar entender as dependências entre os serviços do Azure para ajudar a arquitetar melhor seus aplicativos e serviços, você pode solicitar a documentação de dependência de serviço do Azure entrando em contato com seu representante de vendas ou cliente da Microsoft. Este documento lista as dependências dos serviços do Azure, incluindo as dependências de quaisquer serviços internos importantes comuns, como serviços de plano de controle. Para obter essa documentação, você deve ser um cliente da Microsoft e ter o contrato de confidencialidade (NDA) apropriado com a Microsoft.

Próximos passos