Meu cliente fabrica um dispositivo médico que faz diversas medições de uma determinada amostra e grava os resultados em um banco de dados. A quantidade de dados gerados é relativamente pequena.
Na configuração atual, cada dispositivo possui seu próprio computador e esse computador executa uma instância de um servidor de banco de dados. Os dispositivos não estão em rede.
O cliente deseja modificar o dispositivo de forma que cerca de cinquenta deles possam ser conectados a uma rede local.
Os dispositivos utilizam vários consumíveis que são numerados de lote e, uma vez usados, não podem ser usados novamente. Esses números de lote são gravados no banco de dados quando uma amostra é medida. Este requisito é notável porque na configuração atual um dispositivo não tem como saber se um consumível foi usado por um dispositivo diferente. Na configuração de rede proposta, existe a expectativa de que cada dispositivo tenha acesso imediato a informações sobre consumíveis utilizados por outros dispositivos.
Os dispositivos também precisam rastrear a quantidade de vários produtos químicos usados no processo de teste. Cada frasco de produto químico tem lote numerado e código de barras. Quando uma garrafa é inserida na máquina, a máquina lê o banco de dados para determinar quanto líquido foi consumido da garrafa. Existe a expectativa de que uma garrafa numerada de lote possa ser inserida em qualquer máquina e a máquina seja capaz de avaliar com precisão a quantidade de líquido na garrafa.
O cliente deseja uma recomendação sobre qual das duas arquiteturas deve ser utilizada:
1.) Cada dispositivo gravará dados em seu próprio banco de dados local, como faz agora. O software de sincronização será instalado em cada dispositivo e a sincronização será realizada em tempo real. Cada dispositivo transmitirá periodicamente uma pulsação (foram propostos intervalos de 1 a 5 minutos) e essa pulsação conterá uma soma de verificação CRC. Cada dispositivo na rede escutará os batimentos cardíacos. Um dispositivo iniciará uma sincronização se o CRC de pulsação for diferente do seu. O software de sincronização deve ser externo e independente do software que executa os testes. Portanto, é teoricamente possível, mas não provável, que um dispositivo funcione enquanto estiver desconectado da rede ou enquanto o software de sincronização não estiver em execução.
2.) O servidor de banco de dados de cada dispositivo será removido e um servidor de banco de dados será usado em seu lugar.
O cliente está preocupado com o fato de que, se um servidor de banco de dados for usado, todos os dispositivos da rede ficarão inutilizáveis em caso de falha do servidor. O uso de uma topologia peer reduz efetivamente esse risco? Em outras palavras, se um peer na rede falhar, o negócio continuará normal para todos os outros peers? Há algum perigo ou benefício na integridade dos dados associado a qualquer uma das abordagens?
Edite em resposta às respostas de iag e MikeyB:
Posso ver como minha pergunta deixa espaço para ambiguidade, então aqui está ela novamente, esperançosamente formulada de uma forma mais significativa.
Em um ambiente cliente-servidor, a falha do servidor é catastrófica porque, se o servidor falhar, todos os clientes serão desligados. Dada essa característica de design, por que alguns sistemas de informação, inventário, financeiros e médicos altamente críticos implementam arquitetura cliente-servidor em vez de peer-to-peer?
Observe que NÃO estou perguntando "Como posso mitigar o risco de falha do servidor?" Estou perguntando "A arquitetura ponto a ponto é uma forma eficaz de mitigar o risco de falha do servidor?" Por que ou por que não? A topologia da rede influencia o design da aplicação? O peer-to-peer introduz a possibilidade de corrupção de dados ou resultados ambíguos?
O seguinte é um exemplo realista do que pode ocorrer em uma topologia de rede ponto a ponto?
DeviceA, DeviceB e DeviceC são computadores em uma rede peer que compartilham um agente comum chamado agente R. Sempre que um peer precisa verificar quanto R está disponível, ele sincroniza com outros peers e calcula a disponibilidade. Um dia, por volta das 13h, o técnico do laboratório insere um frasco de R no DispositivoB. DeviceB sincroniza imediatamente com DeviceC e confirma que DeviceC nunca consumiu R daquela garrafa. O DeviceA, no entanto, não responde aos pings desde o meio-dia. O DeviceB pode calcular com segurança a quantidade de R disponível na garrafa?
Sou engenheiro de software e escreverei o aplicativo que permite que esses dispositivos compartilhem dados em uma rede. Honestamente, tenho uma opinião sobre a pergunta que estou fazendo, mas meu cliente não confia na minha experiência. Quero conhecer a experiência dos meus colegas, daí meu post aqui. Não quero colocar palavras na boca de ninguém, por isso estou tentando não ser o mais genérico possível e ainda assim explicar o assunto.
Responder1
Uma arquitetura de software ponto a ponto pode ser uma maneira eficiente e tolerante a falhas de disseminar informações entre nós, presumindo que você já tenha redundância na rede subjacente.
A arquitetura ponto a ponto também pode protegê-lo contra perda de dados se vários nós mantiverem os dados. Em sistemas ponto a ponto típicos, os nós mantêm os dados devido ao seu próprio interesse. O que você deseja é diferente, pois deseja que eles mantenham os dados por adesão a uma política e não por interesse individual.
Cada nó que armazena tudo o que viu é simples, desde que a quantidade de dados seja limitada. Mas armazenar tudo pode não ser prático devido ao espaço de armazenamento (ou, em alguns cenários, devido a requisitos legais). Então é preciso ter cuidado com o que excluir e o que manter. Esta é uma das principais armadilhas.
Mas tudo isso não contribui em nada para resolver a questão da integridade e consistência dos dados. Se você simplesmente mudar para uma arquitetura ponto a ponto sem pensar na correção dos dados, a robustez do sistema nesse aspecto diminuirá. Há simplesmente muito mais lugares onde a corrupção pode ser introduzida.
Para implementar tal solução, você precisa descobrir como validar a integridade de um dado.
Um dado que só pode ser atualizado por um nó específico do sistema é o mais fácil de lidar. Mas você ainda precisa fazer a pergunta sobre qual é o comportamento aceitável do sistema, se esse nó começar a se comportar mal. Fazer com que o nó assine criptograficamente cada atualização não é suficiente, se ele puder enviar erroneamente uma atualização assinada para excluir tudo o que escreveu anteriormente ou para enviar várias atualizações assinadas que discordam sobre qual é o novo valor dos dados. Novamente, uma abordagem simples é armazenar tudo e exigir intervenção manual, caso apareçam atualizações conflitantes. Mas se você precisar tomar qualquer tipo de decisão automatizada com base nos dados, isso será insuficiente.
Se apenas um nó puder atualizar os dados, mas você tiver uma exigência estrita de que todos os outros concordem sobre qual atualização ele realizou, o problema se tornará um pouco mais difícil.
A solução para este problema ainda não é extremamente complicada e dá uma boa ideia dos tipos de métodos utilizados para resolver tais problemas de integridade de dados.
- A atualização do nó assina os dados atualizados e os distribui pela rede ponto a ponto
- Os nós receptores assinam a primeira versão recebida e a enviam de volta ao nó de atualização
- Uma vez que o nó de atualização possui assinaturas de mais de 2/3 de todos os nós (incluindo ele mesmo), ele distribui os dados pela rede ponto a ponto novamente com a coleta de assinaturas.
- Cada nó que receber esta versão validada pelas assinaturas de 2/3 continuará retransmitindo (com backoff exponencial) para todos os nós que ainda não confirmaram que armazenaram permanentemente a versão final dos dados.
O nó autorizado a enviar a atualização em primeiro lugar poderia falhar de uma forma que impediria que os dados fossem atualizados novamente. Mas, desde que envie uma atualização consistente, acabará sendo armazenado de forma consistente em toda a rede ponto a ponto.
Pode parecer que o grande número de assinaturas necessárias em cada dado exigirá muito espaço de armazenamento. Felizmente, isso pode ser evitado através de um método conhecido como assinaturas de limite.
Mas se você deseja substituir um banco de dados, não basta que um nó possa atualizar um dado. Você tem vários nós, que têm permissão para atualizar os mesmos dados, mas exige que toda a rede concorde sobre quem foi o primeiro. É aqui que entra em cena o acordo bizantino.
As soluções para isso são muito mais complicadas do que as que descrevi acima. Mas posso mencionar alguns resultados importantes que você deve conhecer.
Você tem que escolher entre dois modelos de falha. Você pode presumir que um nó com falha simplesmente para de se comunicar e nunca envia uma única mensagem corrompida. Este modelo requer menos hardware, mas basta um único bit invertido para desligar o sistema.
Alternativamente, você pode escolher o modelo de falha bizantina, que permite que um nó com falha faça qualquer coisa e o sistema ainda sobreviverá. Para tolerar tfalhas neste modelo, você precisa 3t+1de nós no total. Em outras palavras, para tolerar um único nó com falha, você precisa de quatro nós. Se você tiver 10 nós no total, é possível tolerar a falha de 3 nós.
Você também deve escolher entre o modelo de comunicação síncrona ou assíncrona. Comunicação síncrona significa que você faz suposições sobre o momento da comunicação. Se os pacotes demorarem mais para chegar ao destino do que o esperado, o sistema falha. Além disso, se um nó travar, você deverá aguardar o atraso máximo permitido antes que o sistema possa continuar.
Os modelos assíncronos tornam o design do software mais complicado, mas apresentam algumas vantagens claras. Você não precisa esperar pelos tempos limite, basta esperar até ouvir mais de 2/3 dos nós antes de poder continuar. Isso pode ser muito mais rápido do que um modelo síncrono em que você precisa de um tempo limite grande.
Outra desvantagem do modelo assíncrono é que ele deve ser randomizado. O tempo de execução do algoritmo torna-se uma variável estocástica sem limite de pior caso. Existe uma possibilidade teórica de que uma atualização leve um tempo infinito, mas a probabilidade disso pode ser zero. E, de fato, o número médio de viagens de ida e volta de comunicação pode ser constante. Para mim, isso parece muito favorável em comparação com o modelo síncrono, que pode falhar em caso de atraso na comunicação.
Como você pode imaginar, acertar esse sistema não é uma tarefa fácil. É necessário um esforço de desenvolvimento dedicado para implementar isso. Além disso, um bug de software ainda pode derrubar o sistema. Se menos de um terço dos nós falharem, o sistema sobreviverá. Mas se existir um bug no software, você poderá muito bem instalar esse software com bugs em mais de um terço dos nós.
Responder2
Estou vendo muitos problemas possíveis aqui.
Primeiro, foram fornecidas a você duas soluções incompletas para consideração que são difíceis de gerenciar conforme apresentadas e intolerantes a falhas.
Segundo, você parece estar confuso sobre como construir serviços de dados. Isso é mais preocupante.
Não tenho certeza de qual é a sua situação de envolvimento com o ambiente descrito, mas recomendo não fazer nada e ter requisitos melhores definidos e um plano melhor para alcançá-los do que caixas aleatórias executando muitos bancos de dados sem backups (ao vivo ou não).
Se a sua preocupação for o inventário do laboratório, existemgrande quantidadede software que resolve isso. Se você estiver trabalhando com esquisitices proprietárias de um fornecedor, estabeleça seus requisitos ambientais, encontre uma maneira de acessar e reter esses dados com algum nível de garantia. Garanto-lhe que isso já foi feito antes.
Nada disso vai acontecer postando perguntas vagas exclusivamente neste fórum. Se você se sentir perdido, deverá reservar algumas horas de um consultor para ajudá-lo.
Responder3
Num determinado ambiente, parece essencial que exista uma única fonte de informação para os dados. Isso é verdade? Não podemos dizer.
Sempre haverá pontos de falha – você precisa projetar em torno do que é aceitável.
Você tem que definir as restrições em torno do seu sistema. Deve haver uma única fonte de dados? Um dispositivo pode usar o inventário enquanto estiver off-line? Uma falha em um único servidor pode ser tolerada? O sistema pode tolerar a operação em modo somente leitura por um curto período?
Depois de ter essas restrições, você descobrirá que ocomode projetar o sistema surge das restrições.