Requisitos de destino e não funcional

Os requisitos de destino e não funcional, como destinos de disponibilidade e destinos de recuperação , permitem que você meça o tempo de atividade e o tempo de indisponibilidade de suas cargas de trabalho. Ter destinos claramente definidos é crucial para ter uma meta para trabalhar e medir. Além desses destinos, há muitos outros requisitos que você deve considerar para melhorar os requisitos de confiabilidade e atender às expectativas dos negócios.

A criação de resiliência (recuperação de falhas) e da disponibilidade (em execução em um estado íntegro sem tempo de inatividade significativo) em seus aplicativos começa com a coleta de requisitos. Por exemplo, quanto tempo de inatividade é aceitável? Quanto o tempo de inatividade potencial custa seus negócios? Quais são os requisitos de disponibilidade do seu cliente? Quanto você investi para tornar seu aplicativo altamente disponível? Qual é o risco em relação ao custo?

Pontos-chave

  • Determine o nível aceitável de tempo de atividade para suas cargas de trabalho.
  • Determine por quanto tempo as cargas de trabalho podem ficar indisponíveis e quantos dados são aceitáveis para serem perdidos durante um desastre.
  • Considere os requisitos de aplicativos e de plataforma de dados para melhorar a resiliência e a disponibilidade.
  • Garanta a disponibilidade da conexão e melhore a confiabilidade com os serviços do Azure.
  • Avalie a integridade geral do aplicativo das cargas de trabalho.

Destinos de disponibilidade

Um Contrato de Nível de Serviço (SLA), é um destino de disponibilidade que representa um compromisso em relação ao desempenho e à disponibilidade do aplicativo. Compreender o SLA de componentes individuais no sistema é essencial para definir destinos de confiabilidade. Conhecer o SLA das dependências também fornecerá uma justificativa para gastos adicionais ao tornar as dependências altamente disponíveis e com contratos de suporte adequados. Os destinos de disponibilidade para qualquer dependência utilizada pelo aplicativo devem ser compreendidos e, idealmente, alinhar-se com os destinos de aplicativo também devem ser considerados.

Entender suas expectativas de disponibilidade é vital para revisar as operações gerais do aplicativo. Por exemplo, se você estiver se empenhando em atingir um objetivo de nível de serviço (SLO) de um aplicativo de 99,999%, o nível de ação operacional inerente exigida pelo aplicativo será muito maior do que se um SLO de 99,9% fosse a meta.

Monitorar e medir a disponibilidade do aplicativo é vital para qualificar a integridade geral do aplicativo e o progresso em relação aos destinos definidos. Certifique-se de medir e monitorar os principais destinos, como:

  • Mean Time entre falhas (MTBF) — o tempo médio entre falhas de um componente específico.
  • Tempo médio de recuperação (MTTR) — o tempo de vida necessário para restaurar um componente após uma falha.

Considerações sobre destinos de disponibilidade

Os SLAs/SLOs/SLIs para todas as dependências utilizadas são compreendidos?


Os destinos de disponibilidade para qualquer dependência utilizada pelo aplicativo devem ser compreendidos e, idealmente, alinhados com os destinos do aplicativo. Certifique-se de que os SLAs/SLOs/SLIs para todas as dependências utilizadas sejam compreendidos.

Um SLA composto foi calculado para os cenários de aplicativo e/ou chave usando os SLAs do Azure?


Um SLA composto captura o SLA de ponta a ponta em todos os componentes e dependências de aplicativos. Ele é calculado usando os SLAs individuais dos componentes de aplicativo de Hospedagem de serviços do Azure e fornece um indicador importante de disponibilidade projetada em relação às expectativas e aos destinos dos clientes. Certifique-se de que o SLA composto de todos os componentes e dependências nos caminhos críticos seja compreendido. Para saber mais, confira SLAs compostos.

Observação

Se você tiver compromissos contratuais com um SLA para sua solução do Azure, as concessões adicionais sobre o SLA de composição do Azure devem ser feitas para acomodar interrupções causadas por problemas e implantações no nível de código. Isso geralmente é ignorado e os clientes colocam diretamente o SLA composto encaminhado para seus clientes.

Os destinos de disponibilidade são considerados enquanto o sistema está sendo executado no modo de recuperação de desastre?


Os destinos de disponibilidade podem ou não ser aplicados durante a execução no modo de recuperação de desastre. Isso depende do aplicativo para o aplicativo. Se os destinos também devem ser aplicados em um estado de falha, um modelo N + 1 deve ser usado para obter maior disponibilidade e resiliência. Nesse cenário, N é a capacidade necessária para fornecer a disponibilidade necessária. Também há uma implicação de custo, pois a infraestrutura mais resiliente geralmente é mais cara. Isso deve ser aceito pelos negócios.

Quais são as consequências se as metas de disponibilidade não forem satisfeitas?


Há penalidades, como cobranças financeiras, associadas à falha ao atender aos compromissos de SLA? Medidas adicionais podem ser usadas para evitar penalidades, mas isso também traz um custo adicional para operar a infraestrutura. Isso deve ser fatorado no e avaliado. Deve ser totalmente compreendido quais são as consequências se as metas de disponibilidade não forem satisfeitas. Isso também informa quando iniciar um caso de failover.

Destinos de recuperação

Os destinos de recuperação identificam por quanto tempo a carga de trabalho pode ficar indisponível e a quantidade de dados aceitável para perda durante um desastre. Defina relatórios de destino para os cenários de aplicativo e chave. Os relatórios de destino necessários são o RTO (objetivo — de tempo de recuperação) o tempo máximo aceitável que um aplicativo está indisponível após um incidente e o RPO (objetivo de ponto de recuperação) — a duração máxima da perda de dados aceitável durante um desastre.

Os destinos de recuperação são requisitos não-funcionais de um sistema e devem ser determinados pelos requisitos de negócios. Os destinos de recuperação devem ser definidos de acordo com os destinos de RTO e RPO necessários para as cargas de trabalho.

Atender aos requisitos da plataforma de aplicativo

Os serviços da plataforma de aplicativos do Azure oferecem recursos de resiliência para dar suporte à confiabilidade do aplicativo, embora possam ser aplicáveis apenas em uma determinada SKU e configuração/implantação. Por exemplo, um SLA depende do número de instâncias implantadas ou de um determinado recurso habilitado. É recomendável que você examine o SLA para os serviços usados. por exemplo, Barramento de Serviço Premium SKU fornece latência previsível e taxa de transferência para mitigar cenários de vizinho ruidosas. ele também fornece a capacidade de dimensionar e replicar automaticamente os metadados para outra instância de Barramento de Serviço para fins de failover.

para saber mais, confira Azure Barramento de Serviço Premium SKU.

Várias regiões emparelhadas

Uma plataforma de aplicativo deve ser implantada em várias regiões se os requisitos ditarem. A cobertura dos requisitos usando zonas é mais barata e menos complexa. O isolamento regional deve ser uma medida extra se os SLAs fornecidos pela configuração de zona cruzada de região única forem insuficientes ou se forem exigidos por uma dispersão geográfica dos usuários.

A capacidade de responder a cenários de desastre para disponibilidade geral da plataforma de computação e resiliência do aplicativo depende do uso de várias regiões ou de outros locais de implantação.

Use regiões emparelhadas que existem na mesma geografia e forneça recursos de replicação nativa para fins de recuperação, como a replicação assíncrona de Geo-Redundant Armazenamento (GRS). No caso de manutenção planejada, as atualizações para uma região serão executadas em sequência apenas. Para saber mais, confira continuidade de negócios com regiões emparelhadas do Azure.

Zonas de Disponibilidade e conjuntos

Os serviços de plataforma que podem aproveitar Zonas de Disponibilidade são implantados de forma zonada em uma zona específica ou em uma configuração com redundância de zona em várias zonas. Para saber mais, confira criando soluções para alta disponibilidade usando o zonas de disponibilidade.

Um conjunto de disponibilidade (AS) é um constructo lógico para informar ao Azure que ele deve distribuir instâncias de máquina virtual contidas em vários domínios de falha e atualização em uma região do Azure. Zonas de Disponibilidade (AZ) eleva o nível de falha para máquinas virtuais em um datacenter físico, permitindo que as instâncias de réplica sejam implantadas em vários datacenters dentro de uma região do Azure. Embora as zonas forneçam maior resiliência do que os conjuntos, há considerações de desempenho e custo em que os aplicativos são extremamente "informativos" entre as zonas, considerando a separação física implícita e encargos de largura de banda entre zonas. por fim, as máquinas virtuais do azure e os serviços de PaaS do azure, como o Service Fabric e o AKS (serviço Kubernetes do azure) que usam máquinas virtuais abaixo, podem aproveitar o AZs ou um para fornecer resiliência de aplicativo em uma região. Para saber mais, confira continuidade de negócios com resiliência de dados.

Considerações sobre disponibilidade

O aplicativo é hospedado em dois ou mais nós de plataforma de aplicativo?


Para garantir a confiabilidade da plataforma de aplicativos, é vital que o aplicativo seja hospedado em pelo menos dois nós para garantir que não haja pontos únicos de falha. Idealmente, um modelo de n + 1 deve ser aplicado para disponibilidade de computação, em que n é o número de instâncias necessárias para dar suporte aos requisitos de desempenho e disponibilidade do aplicativo.

Observação

SLAs mais altos fornecidos para máquinas virtuais e serviços de plataforma relacionados associados exigem pelo menos dois nós de réplica implantados em um conjunto de disponibilidade ou em dois ou mais Zonas de Disponibilidade. Para saber mais, consulte SLA para máquinas virtuais.

Como o tráfego de cliente é roteado para o aplicativo no caso de uma interrupção de região, zona ou rede?


No caso de uma grande interrupção, o tráfego do cliente deve ser roteável para implantações de aplicativo que permanecem disponíveis em outras regiões ou zonas. Isso é basicamente onde a conectividade entre locais e o balanceamento de carga global devem ser usados, dependendo se o aplicativo é interno e/ou voltado para o público. serviços como o Azure Front Door, Gerenciador de Tráfego do Azure ou CDNs de terceiros podem rotear o tráfego entre regiões com base na integridade do aplicativo solicitada por meio de investigações de integridade. para saber mais, consulte monitoramento de ponto de extremidade Gerenciador de Tráfego.

Atender aos requisitos da plataforma de dados

Os serviços de dados e armazenamento devem estar em execução em uma configuração/SKU altamente disponível. Os serviços da plataforma de dados do Azure oferecem recursos de resiliência para dar suporte à confiabilidade do aplicativo, embora possam ser aplicáveis apenas em um determinado SKU. os exemplos são Banco de Dados SQL do Azure SKUs Comercialmente Crítico ou ZRS (Armazenamento com redundância de zona) do Azure Armazenamento com três réplicas síncronas espalhadas pelas zonas de disponibilidade.

Consistência de dados

Os tipos de dados devem ser categorizados pelos requisitos de consistência de dados. Os requisitos de consistência de dados, como consistência forte ou eventual, devem ser compreendidos para todos os tipos de dados e usados para informar o agrupamento e a categorização de dados, bem como quais estratégias de replicação/sincronização de dados podem ser consideradas para atender aos destinos de confiabilidade do aplicativo.

O teorema CAP prova que é impossível que um armazenamento de dados distribuído forneça simultaneamente mais de duas garantias:

  • Consistência – Cada leitura recebe a gravação mais recente ou um erro.
  • Disponibilidade – Cada solicitação recebe uma resposta sem erro, sem a garantia de que ela contém a gravação mais recente.
  • Tolerância à partição – Um sistema continua a operar apesar de um número arbitrário de transações sendo descartados ou atrasados pela rede entre nós.

Determinar qual dessas garantias é mais importante no contexto dos requisitos de aplicativo é essencial.

Replicação e redundância

Replicar dados entre zonas ou regiões emparelhadas dá suporte aos objetivos de disponibilidade do aplicativo para limitar o impacto de cenários de falha. A capacidade de restaurar dados de um backup é essencial ao recuperar de situações de corrupção de dados, bem como cenários de falha. Para garantir redundância e disponibilidade suficientes para cenários de falha regional e zonal, os backups devem ser armazenados entre zonas e/ou regiões.

Defina e teste um processo de restauração de dados para garantir um estado de aplicativo consistente. O teste regular do processo de restauração de dados promove a excelência operacional e a confiança na capacidade de recuperar dados em alinhamento com os objetivos de recuperação definidos para o aplicativo.

Considere como o tráfego do aplicativo é roteado para fontes de dados no caso de uma região, uma zona ou uma insaplicação de rede. Entender o método usado para rotear o tráfego de aplicativo para fontes de dados no caso de um grande evento de falha é essencial para identificar se os processos de failover atenderão aos objetivos de recuperação. Muitos serviços da plataforma de dados do Azure oferecem funcionalidades de confiabilidade nativa para lidar com falhas importantes, como failover automático do BD Cosmos ou Replicação Geográfica Ativa do BD SQL Azure.

Observação

Alguns recursos como o Azure Armazenamento RA-GRS e o Azure SQL DB Active Geo-Replication exigem failover do lado do aplicativo para pontos de extremidade alternativos em alguns cenários de falha, portanto, a lógica do aplicativo deve ser desenvolvida para lidar com esses cenários.

Requisitos de rede e conectividade

Considere essas diretrizes para garantir a disponibilidade da conexão e melhorar a confiabilidade com os serviços do Azure.

Conectividade

  • Use um balanceador de carga global usado para distribuir tráfego e/ou failover entre regiões. Azure Front Door, Gerenciador de Tráfego do Azure ou serviços de CDN de terceiros podem ser usados para direcionar solicitações de entrada para pontos de extremidade de aplicativos externos implantados em várias regiões. É importante observar que o Gerenciador de Tráfego é um balanceador de carga baseado em DNS, portanto, o failover deve aguardar a propagação de DNS ocorrer. Um valor de TTL (Vida Vida) suficientemente baixo deve ser usado para registros DNS, embora nem todos os ISPs possam fazer isso. Para cenários de aplicativo que exigem failover transparente, Azure Front Door deve ser usado. Para saber mais, confira Recuperação de desastre usando Gerenciador de Tráfego do Azure e Azure Front Door de roteamento.

  • Para conectividade entre locais (ExpressRoute ou VPN), verifique se há conexões redundantes de locais diferentes. Pelo menos duas conexões redundantes devem ser estabelecidas em duas ou mais regiões do Azure e locais de peering para garantir que não haja nenhum ponto único de falha. Uma configuração compartilhada de carga ativa/ativa fornece diversidade de caminho e promove a disponibilidade de caminhos de conexão de rede. Para saber mais, confira Conectividade entre redes.

  • Simule um caminho de falha para garantir que a conectividade está disponível em caminhos alternativos. A falha de um caminho de conexão em outros caminhos de conexão deve ser testada para validar a conectividade e a eficácia operacional. O uso da conectividade VPN Site a Site como um caminho de backup para o ExpressRoute fornece uma camada adicional de resiliência de rede para conectividade entre locais. Para saber mais, confira Usando VPN site a site como um backup para o peering privado do ExpressRoute.

  • Elimine todos os pontos de falha individuais do caminho de dados (local e Azure. NVAs (Dispositivos de Virtualização de Rede) de instância única, sejam eles implantados no Azure ou em um datacenter local, apresentam um risco significativo de conectividade. Para saber mais, confira Implantar dispositivos de virtualização de rede altamente disponíveis.

Serviços com conhecimento de zona

  • Use Gateways de Rede Virtual com redundância de zona do ExpressRoute/VPN. Os gateways de rede virtual com redundância de zona distribuem instâncias de gateway Zonas de Disponibilidade para melhorar a confiabilidade e garantir a disponibilidade durante cenários de falha que impactam um datacenter em uma região. Para saber mais, confira Gateways de Rede Virtual com redundância de zona.

  • Se usado, implante o Gateway de Aplicativo do Azure v2 implantado em uma configuração com redundância de zona. Gateway de Aplicativo do Azure v2 pode ser implantado em uma configuração com redundância de zona para implantar instâncias de gateway entre zonas para maior confiabilidade e disponibilidade durante cenários de falha que impactam um datacenter em uma região. Para saber mais, confira Gateway de Aplicativo com redundância de zona v2.

  • Use Azure Load Balancer Standard para balancear a carga do tráfego entre Zonas de Disponibilidade. Azure Load Balancer O Standard é ciente de zona para distribuir o tráfego entre Zonas de Disponibilidade. Ele também pode ser configurado em uma configuração com redundância de zona para melhorar a confiabilidade e garantir a disponibilidade durante cenários de falha que impactam um datacenter em uma região. Para saber mais, confira Standard Load Balancer e Zonas de Disponibilidade.

  • Configure investigações de Azure Load Balancer(s)/Aplicativo Azure Gateways. As investigações de saúde permitem que os Azure Load Balancers avaliem a saúde dos pontos de extremidade de back-end para impedir que o tráfego seja enviado para instâncias não árias. Para saber mais, confira Load Balancer de saúde.

  • Avalie as dependências críticas do aplicativo com investigações de saúde. As investigações de saúde personalizadas devem ser usadas para avaliar a saúde geral do aplicativo, incluindo componentes downstream e serviços dependentes, como APIs e datastores, para que o tráfego não seja enviado para instâncias de back-end que não podem processar solicitações com êxito devido a falhas de dependência. Para saber mais, confira Padrão de monitoramento de ponto de extremidade de saúde.

Próxima etapa

Go back ao artigo principal: Design