A passagem de mensagens pode ser usada para uma redundância de CPU e construção de balanceamento de carga


8

Em sistemas embarcados bare metal ou tipo RTOS mínimo com vários processadores, é possível ter um programa idêntico em execução em cada processador que usa MPI (Message Passing Interface) para fornecer balanceamento de carga e também redundância em caso de falha do processador? Como uma máquina de estado que altera as ações que outras CPUs executam com base em mensagens passadas, por exemplo, solicitando que outro processador assuma parte do loop do sistema para balancear a carga ou enviar mensagens ativas periódicas e lembrar o que cada CPU é responsável até Redundância de CPU.

Neste diagrama de exemplo, as partes reais do loop completo do sistema que estão "abertas" podem ser quaisquer sistemas distintos. Não poderia haver cooperação apenas a capacidade de abrir e / ou fechar partes do loop completo do sistema em execução em cada CPU em uma espécie de multiprocessamento assimétrico muito primitivo. A "migração de processo" para outra CPU seria acionada por uma solicitação de outra CPU para abrir a parte do loop do sistema após o qual a CPU solicitante fecha sua parte ou por uma falta de resposta de outra CPU quando consultada se estiver ativa por algum tempo .

insira a descrição da imagem aqui

Foi proposto como uma solução para falha potencial do processador e solução para balanceamento de carga, uma vez que não podemos portar um sistema operacional incorporado para executar verdadeiramente um multiprocessamento simétrico ou assimétrico na placa personalizada, e parece que isso é teoricamente possível, mas com um design incrivelmente ruim. idéia. Além disso, não consegui encontrar nenhum padrão ou algoritmo de design para usar a passagem de mensagens dessa maneira.

Alguns antecedentes importantes para as decisões de engenharia de software: Um projeto CubeSat de aluno (não classificado ou para uma turma), temos uma pequena equipe de desenvolvimento de software, composta principalmente por estudantes juniores, com pouco ou nenhum conhecimento em design de sistemas operacionais. Por várias razões, não podemos fazer nenhuma das muitas soluções do mundo real que já li. Enquanto isso, parece possível que isso introduza muita complexidade para a equipe lidar, e mesmo que isso possa ser feito, causará um design terrível que levará a algum problema que transforma o CubeSat em uma rocha em órbita.

Não tenho certeza de que poderíamos implementar a passagem de mensagens de maneira confiável o suficiente para realizar viagens espaciais, nem sequer consegui encontrar protocolos de comunicação prontos para produção que possam ser usados ​​para passar mensagens em um barramento com um sistema operacional minúsculo ou simples. metal como precisamos. Mas também estou curioso para saber se esta solução proposta para migração de processos, redundância de CPU e balanceamento de carga é viável para um sistema crítico de segurança. Parece que isso pode levar a um estado em que duas CPUs estão executando o mesmo "Processo" ou parte do loop do programa, se uma acordar que seria difícil de detectar.


Algumas perguntas: (1) como os dados são transmitidos? existe um barramento de passagem de dados de rede ou entre processadores? É improvável que todos os processadores possam compartilhar o acesso aos mesmos bancos de memória ao mesmo tempo, diferentemente dos processadores de uso geral (desktop / servidor). (2) como lidar com equipamentos (sensores e atuadores) conectados por fio a um único processador?
Rwong #

1
Os dados precisariam ser transmitidos usando o UART ou o I2C; se usássemos memória compartilhada, poderíamos também fazer o SMP, mas as coisas que li sobre a implementação que (de preferência por SPI), como barreiras de memória, nem são abordadas em nosso curso de graduação de sistemas operacionais e muito menos. implementação de mutex, semáforo, etc. A equipe de engenharia elétrica e de computadores me garantiu que todas as CPUs seriam conectadas a cada dispositivo periférico, mas o design da placa não está nem perto do fim.
8bit.wappen

Não vejo como você pode obter redundância de CPU e equilíbrio de carga ao mesmo tempo. Se você distribuir tarefas diferentes para cada CPU, não haverá redundância (se a CPU falhar, ela poderá parar de responder, mas provavelmente fará algo aleatório, geralmente devido aos efeitos da radiação, mas continue respondendo). Para redundância, todas as tarefas devem ser executadas em todos os processadores. Se o balanceamento de carga for mais importante que a redundância, seu esquema parecerá bastante simples. Eu apenas implementaria cada parte como uma tarefa diferente em vez de ramificações de uma única tarefa (assumindo que o seu RTOS é multitarefa).
André Sassi

@ AndréSassi: AFAICT você começa com redundância e algum balanceamento de carga e, se algo der errado com algumas das CPUs, você migra as tarefas para outras CPUs, resultando em maior carga por CPU e talvez até em uma taxa de transferência reduzida. tarefas prioritárias ou taxa de erro não crítica mais alta. Isso ainda é melhor do que falhar completamente.
9000

Qual é a vantagem desse sistema em vez de executar todas as tarefas em todos os processadores?
User253751 29/05

Respostas:


1

Excelentes perguntas, porque na verdade eu trabalhei nisso em meados dos anos 90. As naves espaciais são caras e é difícil modificar o software uma vez em órbita. Pensei em uma variante desse problema ao pensar em como os recursos de software de naves espaciais poderiam ser realocados com base nas mudanças nos requisitos das missões. No que diz respeito ao laboratório (VxWorks):

  1. Estimar o carregamento de tarefas para o essencial para cada processador, de acordo com os requisitos.
  2. Estimar o carregamento da tarefa para o conjunto de tarefas da submissão. Essa é a nova configuração desejada, com base no fornecimento das tarefas necessárias por processador necessárias para atender aos requisitos de missão mais importantes. Basicamente, o que você não pode viver sem.
  3. Agora, para cada processador, temos um modelo de tarefa de missão principal e variantes do mesmo com base em outros estados de processamento para os quais podemos ter que mudar o mais rapidamente possível. Essa é uma simples adaptação planejada. Nada de especial, apenas conjuntos diferentes de modelos de tarefas, estimulando e estimulando alguns estímulos. O balanceamento de carga em minhas experiências foi essencialmente pré-planejado. Usamos o agendamento básico de RMA para esta operação. Basicamente, essa é uma grande mudança de contexto em um nível de modelo de tarefas em todo o sistema.

O On Station Program atualiza sob um RTOS. Basicamente, conecte um novo conjunto de tarefas, conecte a rede da fila e inicie o fluxo de dados novamente.
Portanto, nesta implementação simples, suspendemos ou removemos algumas tarefas e permitimos que outras fossem executadas. Nós levamos um pouco mais longe no que chamamos de técnica "Transplante de Coração". Isso era para atualizações de software da estação. Poderíamos desconectar e redirecionar as redes de filas dentro do modelo de tarefas. Basicamente, desconecte a tarefa e elimine-a, se desejado, elimine as filas e reconecte a nova tarefa (coração) e as artérias (rede de filas). Fizemos esse tempo de reprodução em 1995/96. Eu não apenas queria adicionar funcionalidades, mas também remover as que não são necessárias, pois a memória é um recurso muito limitado. Não sei muito sobre MPI, nunca o usei. É determinístico? Usando a teoria da informação, você não precisa de muito para enviar um sinal de manter vivo. Use bits mínimos. As informações mais comuns, como "manter vivo", levam apenas um pouco, verdadeiro ou falso. Eventos que ocorrem com uma probabilidade muito menor precisam de mais bits para representar. Elimine qualquer sobrecarga de software possível. Siga o princípio do KISS (Mantenha as coisas simples ... Estúpidas!).

Agora proteção contra radiação de algum tipo. Projeto do aluno significa provável vôo do CMOS. Eu pelo menos colocava verificações de CRC na memória e executava um cão de guarda para detectar erros como a radiação prolongada faz coisas estranhas na eletrônica. Efeitos de perturbação de evento único podem ser mitigados usando CRC na memória. A trava requer uma redefinição de inicialização.

Sugiro tentar algo como o FreeRTOS e ver quais recursos você pode curvar à sua vontade. O espaço é um ambiente muito desafiador. Diverta-se.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.