Metodologia de conceção para cargas de trabalho críticas para a missão no Azure
A criação de uma aplicação crítica para a missão em qualquer plataforma cloud requer conhecimentos técnicos significativos e investimento em engenharia, especialmente porque existe uma complexidade significativa associada a:
- Compreender a plataforma na cloud,
- Escolher os serviços e a composição corretos,
- Aplicar a configuração de serviço correta,
- Operacionalizar serviços utilizados e
- Está constantemente a alinhar-se com as melhores práticas mais recentes e os roteiros de serviço.
Esta metodologia de design esforça-se por proporcionar um caminho de estrutura fácil de seguir para ajudar a navegar nesta complexidade e informar as decisões de conceção necessárias para produzir uma arquitetura de destino ideal.
1 — Requisitos de conceção para empresas
Nem todas as cargas de trabalho críticas para a missão têm os mesmos requisitos. Espere que as considerações de revisão e as recomendações de conceção fornecidas por esta metodologia de design produzam diferentes decisões de design e compromissos para diferentes cenários de aplicações.
Selecionar um escalão de fiabilidade
A fiabilidade é um conceito relativo e para que qualquer carga de trabalho seja adequadamente fiável, deve refletir os requisitos empresariais que a rodeiam. Por exemplo, uma carga de trabalho crítica para a missão com um Objetivo de Nível de Serviço (SLO) de disponibilidade de 99,999% requer um nível de fiabilidade muito mais elevado do que outra carga de trabalho menos crítica com um SLO de 99,9%.
Esta metodologia de conceção aplica o conceito de escalões de fiabilidade expressos como SLOs de disponibilidade para informar as características de fiabilidade necessárias. A tabela abaixo captura os orçamentos de erro permitidos associados a escalões de fiabilidade comuns.
| Escalão de Fiabilidade (SLO de Disponibilidade) | Período de Inatividade Permitido (Semana) | Período de Inatividade Permitido (Mês) | Período de Inatividade Permitido (Ano) |
|---|---|---|---|
| 99,9% | 10 minutos, 4 segundos | 43 minutos, 49 segundos | 8 horas, 45 minutos, 56 segundos |
| 99,95% | 5 minutos, 2 segundos | 21 minutos, 54 segundos | 4 horas, 22 minutos, 58 segundos |
| 99,99% | 1 minutos | 4 minutos e 22 segundos | 52 minutos, 35 segundos |
| 99,999% | 6 segundos | 26 segundos | 5 minutos, 15 segundos |
| 99.9999% | <1 segundo | 2 segundos | 31 segundos |
Importante
O SLO de Disponibilidade é considerado por esta metodologia de design como mais do que um tempo de atividade simples, mas sim um nível consistente de serviço da aplicação em relação a um estado de aplicação em bom estado de funcionamento conhecido.
Como exercício inicial, os leitores são aconselhados a selecionar um escalão de fiabilidade de destino ao determinar quanto tempo de inatividade é aceitável? A prossecução de um determinado escalão de fiabilidade terá, em última análise, uma influência significativa no caminho de conceção e decisões de conceção englobadas, o que resultará numa arquitetura de destino diferente.
Esta imagem mostra como os diferentes escalões de fiabilidade e os requisitos empresariais subjacentes influenciam a arquitetura de destino para uma implementação de referência conceptual, especialmente no que diz respeito ao número de implementações regionais e às tecnologias globais utilizadas.
para a missão
O Objetivo de Tempo de Recuperação (RTO) e o Objetivo de Ponto de Recuperação (RPO) são aspetos críticos adicionais ao determinar a fiabilidade necessária. Por exemplo, se estiver a tentar alcançar um RTO de aplicação com menos de um minuto, é provável que as estratégias de recuperação baseadas em cópias de segurança ou uma estratégia de implementação ativa-passiva sejam insuficientes.
2 — Avaliar as áreas de estrutura com os princípios de estrutura
No cerne desta metodologia encontra-se um caminho de design crítico composto por:
- Princípios de conceção fundamentais
- Área de design fundamental com decisões de design fortemente interligadas e dependentes.
O impacto das decisões tomadas em cada área de design reverterá entre outras áreas de design e decisões de design. Reveja as considerações e recomendações fornecidas para compreender melhor as consequências de decisões englobadas, que podem produzir compensações em áreas de design relacionadas.
Por exemplo, para definir uma arquitetura de destino, é fundamental determinar a melhor forma de monitorizar o estado de funcionamento da aplicação entre componentes principais. Recomendamos vivamente que reveja a área de design de modelação de estado de funcionamento, utilizando as recomendações descritas para ajudar a impulsionar decisões.
3 — Implementar a sua primeira aplicação crítica para a missão
Veja estas arquiteturas de referência que descrevem as decisões de conceção com base nesta metodologia.
Arquitetura de linha de base de uma aplicação com acesso à Internet
Arquitetura de linha de base de uma aplicação com acesso à Internet com controlos de rede
Dica
A arquitetura é apoiada pela implementação Mission-Critical Online que ilustra as recomendações de design.
Artefactos de nível de produção Todos os artefactos técnicos estão prontos para serem utilizados em ambientes de produção com todos os aspetos operacionais ponto a ponto considerados.
Enraizado em experiências do mundo real Todas as decisões técnicas são orientadas por experiências de clientes do Azure e lições aprendidas com a implementação dessas soluções.
Alinhamento do mapa de objetivos do Azure As arquiteturas de referência críticas para a missão têm o seu próprio mapa de objetivos que está alinhado com os roteiros dos produtos do Azure.
4 — Integrar a carga de trabalho nas zonas de destino do Azure
As subscrições de zona de destino do Azure fornecem uma infraestrutura partilhada para implementações empresariais que precisam de governação centralizada.
É crucial avaliar que caso de utilização de conectividade é necessário para a sua aplicação crítica para a missão. As zonas de destino do Azure suportam dois arquétipos principais separados em diferentes âmbitos do Grupo de Gestão: Online ou Corp. conforme mostrado nesta imagem.
Subscrição online
Uma carga de trabalho crítica para a missão funciona como uma solução independente, sem qualquer conectividade de rede empresarial direta ao resto da arquitetura da zona de destino do Azure. A aplicação será ainda salvaguardada através da governação orientada por políticas e será integrada automaticamente com o registo centralizado da plataforma através da política.
A arquitetura de linha de base e a implementação Mission-Critical Online alinham-se com a abordagem Online.
Subscrição corp.
Quando implementada numa subscrição corp. uma carga de trabalho crítica para a missão depende da zona de destino do Azure para fornecer recursos de conectividade. Esta abordagem permite a integração com outras aplicações e serviços partilhados. Terá de estruturar alguns recursos fundamentais, que existirão antecipadamente como parte da plataforma de serviço partilhado. Por exemplo, o carimbo de implementação regional já não deve abranger um Rede Virtual efémero ou a Zona de DNS Privado do Azure, uma vez que estes irão existir na subscrição corp.
Para começar a utilizar este caso de utilização, recomendamos a arquitetura de linha de base numa arquitetura de referência da zona de destino do Azure.
Dica
A arquitetura anterior é apoiada pela implementação Mission-Critical Connected .
5 — Implementar um ambiente de aplicação sandbox
Em paralelo com as atividades de design, recomenda-se vivamente que seja estabelecido um ambiente de aplicação sandbox com as implementações de referência Mission-Critical.
Isto proporciona oportunidades práticas para validar decisões de conceção ao replicar a arquitetura de destino, permitindo que a incerteza de design seja rapidamente avaliada. Se aplicado corretamente com a cobertura de requisitos representativos, os problemas mais problemáticos susceptíveis de dificultar o progresso podem ser detetados e posteriormente resolvidos.
6 — Evoluir continuamente com os roteiros do Azure
As arquiteturas de aplicações estabelecidas com esta metodologia de design têm de continuar a evoluir em linha com os roteiros da plataforma do Azure para suportar a sustentabilidade otimizada.
Passo seguinte
Reveja os princípios de design para cenários de aplicação críticos para a missão.