Por Chris Merrill*
O modelo de transmissão tradicional para os 99% de desempenho ininterrupto frequentemente citados requer a duplicação de todos os componentes essenciais na cadeia de produção. Como os componentes devem estar disponíveis em caso de falha, esses recursos necessariamente permanecem ociosos. Embora isso nunca tenha sido uma boa otimização de recursos, no ambiente de nuvem de hoje, onde o tempo de execução do fluxo de trabalho é medido e todos os recursos, sejam usados ou reservados, têm um custo associado, manter um sistema totalmente redundante em espera ativa é um desperdício.
Muitos dos primeiros componentes hospedados em nuvem oferecidos no mercado de transmissão são desenvolvimentos monolíticos de elevação e mudança que exigem duplicação total na nuvem para preservar o padrão de desempenho ininterrupto, bloqueando assim o custo adicional de redundância.
Para que esses sistemas funcionem, eles contam com redes rígidas com um ambiente operacional muito fixo para manter a conectividade entre si e componentes contribuintes. Qualquer falha dentro do sistema tem o potencial de resultar em falha do sistema sem uma forma normal de recuperação.
Os melhores sistemas baseados em nuvem da atualidade eliminaram essa velha maneira de pensar. Em vez disso, eles se concentram em alcançar o objetivo final, que é um alto nível de resiliência. A resiliência é medida pelo tempo médio de falha do sistema (MTTF) e pelo tempo médio de recuperação (MTTR). Outras medidas de resiliência podem incluir a capacidade do sistema de:
Previsão de falhas potenciais
Isolar componentes impactados
Proteger contra falhas potenciais
Remover as falhas e recuperar de um estado de falha
Restaurar o desempenho ideal do sistema (Muhammad, 2019)
Ao focar no objetivo de resiliência em vez de redundância, torna-se muito mais fácil tomar decisões que medem e melhoram a confiabilidade enquanto otimiza para o menor custo e complexidade do operador.
É da natureza do processamento baseado em nuvem ocasionalmente ter falhas. Um data center pode sofrer perda de energia. Um servidor ou aplicativo pode falhar. Para manter altos padrões de desempenho, a resiliência em sistemas em nuvem deve ser considerada para cada aspecto do design do sistema: a rede, a plataforma e as soluções que são executadas nessas plataformas.
A compensação de falhas potenciais começa com a rede definida por software (SDN). O SDN permite a virtualização de rede em escala e o spin-up de uma infraestrutura de rede virtual para atender às demandas do cliente de forma mais flexível e econômica.
Em um sistema modular bem projetado com capacidade elástica, uma falha não precisa se transformar automaticamente em um erro e depois em falha. Quando uma solução de nuvem é modular até o nível de microsserviços, ela pode permitir estratégias de resiliência que visam cirurgicamente a replicação, redirecionando e reiniciando recursos específicos conforme a necessidade. Cada serviço expõe seu estado – indica ao resto do sistema seu status de saúde – de modo que um mecanismo de detecção de erro eficaz possa fornecer um alerta antecipado de falhas em potencial e isolar, parar e restaurar áreas com problemas potenciais como uma ação preventiva. A falha permanece invisível para o operador do sistema – tudo sem intervenção humana durante o evento de recuperação.
A resiliência na nuvem começa no nível da rede com o conceito de expansão.
Em um fluxo de trabalho de transmissão tradicional, o modelo comum de abordar a produção em grande escala era comprar os maiores frames de processamento de hardware disponíveis. Muitas empresas, incluindo Grass Valley, estabeleceram liderança de mercado no fornecimento de equipamentos com a maior capacidade de processamento possível. Independentemente do tamanho, esses recursos de processamento têm um limite tanto em termos de número de cálculos possíveis quanto de acesso geográfico aos processadores.
Em sistemas de nuvem bem projetados, em vez de maximizar a capacidade de uma única máquina, a capacidade de processamento adicional é adicionada em vários servidores que compartilham o trabalho. Os servidores são implantados e orquestrados conforme necessário com algo como Amazon ECS ou uma tecnologia como Kubernetes. Ao contrário do dimensionamento, que tem um único local, um único status de saúde e um tamanho máximo, o dimensionamento fornece capacidade essencialmente ilimitada de dimensionamento, acesso geo-agnóstico e muito mais elasticidade para contornar falhas.
Modelos de escalonamento vs. escalonamento dos tempos de resposta de recuperação de impacto. Não existe uma solução única para todos. A quantidade desejada de tempo de resposta e recurso de espera deve ser projetado usando os Acordos de Nível de Serviço dos serviços de nuvem individuais no design.
Uma arquitetura modular semelhante para a solução SaaS em execução na rede é uma parte crítica das respostas preventivas a falhas. O sistema de controle monitora a saúde de cada módulo usado na solução. Uma regra geral é: quanto maior a unidade funcional que deve falhar antes que o processo de recuperação seja iniciado, mais tempo o sistema leva para se recuperar.
É por isso que o conceito de microsserviços é tão importante. Uma solução baseada em microsserviços, ao contrário de uma implantação monolítica, torna muito mais fácil e rápido prever e isolar possíveis falhas, enquanto traz novos recursos para compensar. Um sistema monolítico possui apenas um único estado para todo o sistema. Quando todo o sistema está inativo, leva muito mais tempo para se recuperar.
Chris Merrill
Diretor de Marketing de Produto da Grass Valley
