Como o Meta detecta e mitiga ‘erros silenciosos’

Erros silenciosos, como são chamados, são defeitos de {hardware} que não deixam rastros nos logs do sistema. A ocorrência desses problemas pode ser agravada ainda mais por fatores como temperatura e idade. É um problema de todo o setor que representa um grande desafio para a infraestrutura de datacenter, pois eles podem causar estragos em aplicativos por um período prolongado de pace, sem serem detectados.

Em um artigo recém-publicado, Meta detalhou como detecta e mitiga esses erros em sua infraestrutura. A Meta u.s.a. uma abordagem combinada testando tanto enquanto as máquinas estão offline para manutenção quanto para realizar testes menores durante a produção. A Meta descobriu que, embora a metodologia anterior alcance uma cobertura geral maior, os testes em produção podem alcançar uma cobertura robusta em um período de pace muito mais curto.

Erros silenciosos

Erros silenciosos, também chamados de corrupção silenciosa de dados (SDC), são o resultado de uma defeito de {hardware} interno. Para ser mais específico, esses erros ocorrem em locais onde não há lógica de verificação, o que faz com que o defeito não seja detectado. Eles podem ser influenciados ainda mais por fatores como variação de temperatura, variações de caminho de dados e idade.

O defeito causa operação incorreta do circuito. Isso pode se manifestar no nível do aplicativo como um bit invertido em um valor de dados ou pode até levar o {hardware} a executar as instruções erradas. Seus efeitos podem até se propagar para outros serviços e sistemas.

Como exemplo, em um estudo de caso, um cálculo simples em um banco de dados retornou a resposta errada 0, resultando em linhas ausentes e, posteriormente, levou à perda de dados. Na escala da Meta, a empresa relata ter observado centenas de tais SDCs. A Meta encontrou uma taxa de ocorrência de SDC de um em mil dispositivos de silício, que afirma refletir os desafios fundamentais do silício, em vez de efeitos de partículas ou raios cósmicos.

A Meta executa estruturas de detecção e teste desde 2019. Essas estratégias podem ser categorizadas em dois grupos: frotascanner para testes fora de produção e ripple para testes em produção.

Funil de teste de silicone

Antes de um dispositivo de silício entrar na frota Meta, ele passa por um funil de teste de silício. Já antes do lançamento durante o desenvolvimento, um chip de silício passa por verificação (simulação e emulação) e, posteriormente, validação de silício em amostras reais. Ambos os testes podem durar vários meses. Durante a fabricação, o dispositivo passa por mais testes (automatizados) no nível do dispositivo e do sistema. Os fornecedores de silício geralmente exploram esse nível de teste para fins de binning, pois haverá variações no desempenho. Chips não funcionais resultam em um menor rendimento de fabricação.

Finalmente, quando o dispositivo chega ao Meta, ele passa por testes de entrada de infraestrutura (burn-in) em muitas configurações de instrument no nível do rack. Tradicionalmente, isso teria concluído o teste, e o dispositivo deveria funcionar pelo resto de seu ciclo de vida, contando com recursos RAS (confiabilidade-disponibilidade-serviço) integrados para monitorar a integridade do sistema.

No entanto, os SDCs não podem ser detectados por esses métodos. Portanto, isso requer padrões de teste dedicados que são executados periodicamente durante a produção, o que requer orquestração e agendamento. No caso mais extremo, esses testes são feitos durante

É notável que quanto mais próximo o dispositivo estiver de executar cargas de trabalho de produção, menor será a duração dos testes, mas também menor será a capacidade de causar raiz (diagnosticar) defeitos de silício. Além disso, o custo e a complexidade dos testes, bem como o impacto potencial de um defeito, também aumentam. Por exemplo, no nível do sistema, vários tipos de dispositivos precisam trabalhar em coesão, enquanto o nível da infraestrutura adiciona aplicativos e sistemas operacionais complexos.

Observações de teste em toda a frota

Erros silenciosos são complicados, pois podem produzir resultados errôneos que não são detectados, além de afetar vários aplicativos. Esses erros continuarão a se propagar até que produzam diferenças perceptíveis no nível do aplicativo.

Além disso, existem vários fatores que afetam sua ocorrência. Meta descobriu que essas falhas se enquadram em quatro categorias principais:

• Randomização de dados. As corrupções tendem a depender dos dados de entrada, por exemplo, devido a certos padrões de bits. Isso cria um grande espaço de estado para teste. Por exemplo, talvez 3 vezes 5 seja avaliado corretamente como 15, enquanto 3 vezes 4 é avaliado como 10.
• Variações elétricas. Mudanças na tensão, frequência e corrente podem levar a maiores ocorrências de corrupção de dados. Sob um conjunto desses parâmetros, o resultado pode ser preciso, enquanto isso pode não ser o caso de outro conjunto. Isso complica ainda mais o espaço de estado de teste.
• Variações ambientais. Outras variações como temperatura e umidade também podem impactar em erros silenciosos, pois podem influenciar diretamente na física associada ao dispositivo. Mesmo em um ambiente controlado como um datacenter, ainda pode haver pontos de acesso. Em explicit, isso pode levar a variações nos resultados entre os datacenters.
• Variações do ciclo de vida. Assim como as falhas regulares do dispositivo, a ocorrência de SDCs também pode variar ao longo do ciclo de vida do silício.

Testes de infraestrutura

A Meta implementou duas categorias de testes em toda a frota em milhões de máquinas. Estes são testes fora de produção e em produção.

Nos testes fora de produção, as máquinas são colocadas offline e sujeitas a padrões conhecidos de entradas. A saída é então comparada às referências. Nesses testes, todas as variáveis ​​discutidas acima são levadas em consideração e testadas em relação ao uso de políticas de pesquisa de estado.

Na maioria das vezes, as máquinas não são especificamente colocadas offline para testes de erros silenciosos, mas são testadas de forma oportunista enquanto a máquina está offline por vários outros motivos, como atualizações de firmware e kernel, provisionamento ou reparo tradicional de servidor.

Durante essa manutenção de servidor, o Meta realiza a detecção silenciosa de erros com uma ferramenta de teste chamada frotascanner. Esta forma de operação minimiza a sobrecarga e, portanto, o custo. Quando uma corrupção silenciosa de dados é detectada, a máquina é colocada em quarentena e submetida a testes adicionais.

Como a saída de produção é lenta, pois tem um longo pace de reação a assinaturas recém-identificadas, o Meta também realiza testes em produção com uma ferramenta chamada ripple. Ele co-localiza com a carga de trabalho e executa instruções de teste em intervalos de nível de milissegundos. A Meta relatou que conseguiu realizar testes de sombra executando testes A/B em diferentes variáveis ​​e também tem a ferramenta sempre ligada. A Meta identificou o teste de ondulação em explicit como uma grande evolução para ferramentas silenciosas de corrupção de dados.

Descobertas e trocas

Com base em três anos de observações, o Fleetscanner alcançou 93% de cobertura para uma determinada família de defeitos e 23% de cobertura única que não technology alcançada pela ondulação. No entanto, o custo é, obviamente, uma quantidade não trivial de pace (e, portanto, custo) que é gasto testando. Por outro lado, a ondulação ofereceu 7% de cobertura única. Meta argumenta que essa cobertura seria impossível de alcançar com o FleetScanner devido à transição frequente de cargas de trabalho com ondulação.

Ao comparar o pace para atingir uma cobertura SDC equivalente de 70%, o Fleetscanner levaria 6 meses em comparação com apenas 15 dias para a ondulação.

Ao permanecerem indetectáveis, os aplicativos podem ficar expostos por meses a corrupções de dados silenciosas. Isso, por sua vez, pode levar a impactos significativos, como perda de dados, que pode levar meses para depurar. Portanto, isso representa um problema crítico para a infraestrutura do datacenter.

A Meta implementou uma metodologia de teste abrangente que consiste em um scanner de frota fora de produção que é executado durante a manutenção para outros fins e um teste de ondulação em produção mais rápido (nível de milissegundos).