Verringert die Verwendung einer Peer-Topologie das Risiko eines Serverausfalls?

Question

Mein Kunde stellt ein medizinisches Gerät her, das verschiedene Messungen einer bestimmten Probe vornimmt und die Ergebnisse in eine Datenbank schreibt. Die generierte Datenmenge ist relativ gering.

In der aktuellen Konfiguration verfügt jedes Gerät über einen eigenen Computer, und auf diesem Computer wird eine Instanz eines Datenbankservers ausgeführt. Die Geräte sind nicht vernetzt.

Der Auftraggeber möchte die Geräte so modifizieren, dass etwa fünfzig davon an ein lokales Netzwerk angeschlossen werden können.

Die Geräte verwenden verschiedene Verbrauchsmaterialien, die Chargennummern haben und nach der Verwendung nicht wiederverwendet werden können. Diese Chargennummern werden bei der Messung einer Probe in die Datenbank geschrieben. Diese Anforderung ist wichtig, da ein Gerät in der aktuellen Konfiguration nicht wissen kann, ob ein Verbrauchsmaterial von einem anderen Gerät verwendet wurde. In der vorgeschlagenen Netzwerkkonfiguration wird erwartet, dass jedes Gerät sofortigen Zugriff auf Informationen über Verbrauchsmaterialien hat, die von anderen Geräten verwendet werden.

Die Geräte müssen auch die Menge der verschiedenen Chemikalien erfassen, die im Testverfahren verwendet werden. Jede Flasche mit Chemikalien ist mit einer Chargennummer und einem Strichcode versehen. Wenn eine Flasche in die Maschine eingesetzt wird, liest diese die Datenbank, um festzustellen, wie viel Flüssigkeit aus der Flasche verbraucht wurde. Es wird erwartet, dass eine Flasche mit Chargennummer in jede Maschine eingesetzt werden kann und die Maschine die Flüssigkeitsmenge in der Flasche genau bestimmen kann.

Der Kunde wünscht sich eine Empfehlung, welche der beiden Architekturen zum Einsatz kommen soll:

1.) Jedes Gerät schreibt Daten wie bisher in seine eigene lokale Datenbank. Auf jedem Gerät wird eine Synchronisierungssoftware installiert und die Synchronisierung wird in Echtzeit durchgeführt. Jedes Gerät sendet in regelmäßigen Abständen einen Heartbeat (Intervalle von 1 bis 5 Minuten wurden vorgeschlagen) und dieser Heartbeat enthält eine CRC-Prüfsumme. Jedes Gerät im Netzwerk wartet auf Heartbeats. Ein Gerät leitet eine Synchronisierung ein, wenn der Heartbeat-CRC von seinem eigenen abweicht. Die Synchronisierungssoftware ist extern und unabhängig von der Software, die die Tests durchführt. Daher ist es theoretisch möglich, aber nicht wahrscheinlich, dass ein Gerät läuft, während es vom Netzwerk getrennt ist oder während die Synchronisierungssoftware nicht läuft.

2.) Der Datenbankserver auf jedem Gerät wird entfernt und stattdessen ein Datenbankserver verwendet.

Der Kunde befürchtet, dass bei Verwendung eines Datenbankservers alle Geräte im Netzwerk im Falle eines Serverausfalls unbrauchbar werden. Wird dieses Risiko durch die Verwendung einer Peer-Topologie effektiv gemindert? Anders ausgedrückt: Wenn ein Peer im Netzwerk ausfällt, läuft dann alles wie gewohnt für alle anderen Peers? Sind mit beiden Ansätzen Gefahren oder Vorteile für die Datenintegrität verbunden?

Bearbeitung als Reaktion auf die Antworten von iag und MikeyB:

Ich sehe, dass meine Frage Raum für Mehrdeutigkeiten lässt, daher hier noch einmal, hoffentlich in einer aussagekräftigeren Formulierung.

In einer Client-Server-Umgebung hat ein Serverausfall katastrophale Folgen, denn wenn der Server ausfällt, werden alle Clients abgeschaltet. Warum implementieren angesichts dieses Designmerkmals einige hochkritische Informations-, Inventar-, Finanz- und medizinische Systeme eine Client-Server-Architektur und nicht eine Peer-to-Peer-Architektur?

Bitte beachten Sie, dass ich NICHT frage: „Wie verringere ich das Risiko eines Serverausfalls?“, sondern: „Ist eine Peer-to-Peer-Architektur eine effektive Möglichkeit, das Risiko eines Serverausfalls zu verringern?“ Warum oder warum nicht? Beeinflusst die Topologie des Netzwerks das Design der Anwendung? Führt Peer-to-Peer zu Datenbeschädigungen oder mehrdeutigen Ergebnissen?

Ist das Folgende ein realistisches Beispiel dessen, was in einer Peer-to-Peer-Netzwerktopologie passieren könnte?

GerätA, GerätB und GerätC sind Computer in einem Peer-Netzwerk, die einen gemeinsamen Agenten namens Agent R verwenden. Wenn ein Peer prüfen muss, wie viel R verfügbar ist, synchronisiert er sich mit anderen Peers und berechnet die Verfügbarkeit. Eines Tages gegen 13 Uhr setzt der Labortechniker eine Flasche R in GerätB ein. GerätB synchronisiert sich sofort mit GerätC und bestätigt, dass GerätC noch nie R aus dieser Flasche verbraucht hat. GerätA hat jedoch seit Mittag nicht mehr auf Pings reagiert. Kann GerätB die in der Flasche verfügbare R-Menge zuverlässig berechnen?

Ich bin Softwareentwickler und werde die Anwendung schreiben, die es diesen Geräten ermöglicht, Daten über ein Netzwerk auszutauschen. Ehrlich gesagt habe ich eine Meinung zu der Frage, die ich stelle, aber mein Kunde vertraut meiner Erfahrung nicht. Ich möchte die Erfahrungen meiner Kollegen kennen, daher mein Beitrag hier. Ich möchte niemandem Worte in den Mund legen, also versuche ich, nicht so allgemein wie möglich zu sein und das Problem trotzdem zu erklären.

Answer 1

Eine Peer-to-Peer-Softwarearchitektur kann eine effiziente und fehlertolerante Möglichkeit sein, Informationen zwischen Knoten zu verbreiten, vorausgesetzt, Sie verfügen bereits über Redundanz im zugrunde liegenden Netzwerk.

Die Peer-to-Peer-Architektur kann Sie auch vor Datenverlust schützen, wenn mehrere Knoten die Daten speichern. In typischen Peer-to-Peer-Systemen speichern Knoten Daten aus eigenem Interesse. Was Sie wollen, ist etwas anderes, da Sie möchten, dass sie Daten speichern, um eine Richtlinie einzuhalten, und nicht aus eigenem Interesse.

Solange die Datenmenge begrenzt ist, ist es einfach, wenn jeder Knoten alles speichert, was er jemals gesehen hat. Aber alles zu speichern, ist aus Speicherplatzgründen (oder in manchen Szenarien aufgrund gesetzlicher Anforderungen) möglicherweise nicht praktikabel. Dann muss man vorsichtig sein, was man löscht und was man behält. Dies ist eine der größten Gefahren.

All dies trägt jedoch nichts zur Lösung des Problems der Datenintegrität und -konsistenz bei. Wenn Sie einfach auf eine Peer-to-Peer-Architektur umsteigen, ohne über die Richtigkeit der Daten nachzudenken, wird die Robustheit des Systems in dieser Hinsicht abnehmen. Es gibt einfach viel mehr Stellen, an denen Korruption auftreten kann.

Um eine solche Lösung zu implementieren, müssen Sie herausfinden, wie Sie die Integrität eines Datenelements überprüfen können.

Ein Datenelement, das immer nur von einem bestimmten Knoten im System aktualisiert werden kann, ist am einfachsten zu handhaben. Sie müssen sich jedoch immer noch die Frage stellen, welches Verhalten des Systems akzeptabel ist, wenn dieser Knoten anfängt, sich falsch zu benehmen. Es reicht nicht aus, wenn der Knoten jedes Update kryptografisch signiert, wenn er fälschlicherweise ein signiertes Update aussenden könnte, um alles zu löschen, was er zuvor geschrieben hat, oder wenn er mehrere signierte Updates aussendet, die sich über den neuen Wert der Daten nicht einig sind. Ein einfacher Ansatz besteht wiederum darin, alles zu speichern und manuelle Eingriffe zu verlangen, wenn widersprüchliche Updates auftauchen. Wenn Sie jedoch jemals eine Art automatisierte Entscheidung auf der Grundlage der Daten benötigen, ist dies unzureichend.

Wenn nur ein Knoten die Daten aktualisieren kann, Sie jedoch die strikte Anforderung haben, dass alle anderen Knoten der von ihm durchgeführten Aktualisierung zustimmen müssen, wird das Problem etwas schwieriger.

Die Lösung dieses Problems ist nicht besonders kompliziert und vermittelt einen guten Eindruck von den Methoden, die zur Lösung solcher Datenintegritätsprobleme eingesetzt werden.

• Der Aktualisierungsknoten signiert aktualisierte Daten und verteilt sie über das Peer-to-Peer-Netzwerk
• Empfangende Knoten signieren die erste empfangene Version und senden sie an den Aktualisierungsknoten zurück.
• Sobald der Aktualisierungsknoten über Signaturen von mehr als zwei Dritteln aller Knoten (einschließlich sich selbst) verfügt, verteilt er die Daten mit der Sammlung der Signaturen erneut über das Peer-to-Peer-Netzwerk.
• Jeder Knoten, der diese durch Signaturen von 2/3 validierte Version erhält, sendet sie (mit exponentiellem Backoff) weiter an alle Knoten, die noch nicht bestätigt haben, dass sie die endgültige Version der Daten dauerhaft gespeichert haben.

Der Knoten, der das Update ursprünglich senden durfte, könnte so ausfallen, dass die Daten nie wieder aktualisiert werden können. Aber solange er ein konsistentes Update sendet, wird es letztendlich konsistent im gesamten Peer-to-Peer-Netzwerk gespeichert.

Es mag so klingen, als würde die große Zahl an Signaturen, die für jedes Datenelement benötigt werden, viel Speicherplatz beanspruchen. Glücklicherweise kann dies durch eine Methode namens Schwellenwertsignaturen vermieden werden.

Wenn Sie jedoch eine Datenbank ersetzen möchten, reicht es nicht aus, dass ein Knoten ein Datenelement aktualisieren kann. Sie haben mehrere Knoten, die dasselbe Datenelement aktualisieren dürfen, aber Sie müssen sich im gesamten Netzwerk darüber einig sein, wer zuerst war. Hier kommt die byzantinische Übereinstimmung ins Spiel.

Die Lösungen hierfür sind um ein Vielfaches komplizierter als das, was ich oben beschrieben habe. Aber ich kann einige wichtige Ergebnisse nennen, die Sie beachten sollten.

Sie müssen zwischen zwei Fehlermodellen wählen. Sie können davon ausgehen, dass ein fehlerhafter Knoten einfach die Kommunikation einstellt und niemals eine einzige beschädigte Nachricht sendet. Dieses Modell erfordert weniger Hardware, aber es genügt ein einziges umgedrehtes Bit, um das System zum Absturz zu bringen.

Alternativ können Sie das byzantinische Ausfallmodell wählen, bei dem ein ausgefallener Knoten alles tun kann und das System trotzdem überlebt. Um tAusfälle in diesem Modell zu tolerieren, benötigen Sie 3t+1insgesamt Knoten. Mit anderen Worten: Um einen einzelnen ausgefallenen Knoten zu tolerieren, benötigen Sie vier Knoten. Wenn Sie insgesamt 10 Knoten haben, ist es möglich, den Ausfall von 3 Knoten zu tolerieren.

Sie müssen sich auch zwischen einem synchronen oder asynchronen Kommunikationsmodell entscheiden. Bei synchroner Kommunikation müssen Sie Annahmen über den Zeitpunkt der Kommunikation treffen. Wenn Pakete länger brauchen, um ihr Ziel zu erreichen, als angenommen, bricht das System zusammen. Wenn außerdem ein Knoten abstürzt, müssen Sie die maximal zulässige Verzögerung abwarten, bevor das System fortfahren kann.

Asynchrone Modelle machen den Softwareentwurf komplizierter, haben aber einige klare Vorteile. Sie müssen nicht auf Timeouts warten, sondern nur, bis Sie von mehr als 2/3 der Knoten gehört haben, bevor Sie fortfahren können. Dies kann viel schneller sein als bei einem synchronen Modell, bei dem Sie ein langes Timeout benötigen.

Ein weiterer Nachteil des asynchronen Modells ist, dass es randomisiert werden muss. Die Laufzeit des Algorithmus wird zu einer stochastischen Variable ohne Worst-Case-Grenze. Es besteht die theoretische Möglichkeit, dass ein Update unendlich lange dauert, aber die Wahrscheinlichkeit dafür kann als Null gezeigt werden. Und tatsächlich kann gezeigt werden, dass die durchschnittliche Anzahl der Kommunikations-Roundtrips konstant ist. Für mich sieht das im Vergleich zum synchronen Modell, das im Falle einer verzögerten Kommunikation zusammenbrechen kann, viel günstiger aus.

Wie Sie sich vorstellen können, ist es keine leichte Aufgabe, ein solches System richtig zu machen. Es bedarf einer engagierten Entwicklungsanstrengung, um dies umzusetzen. Darüber hinaus kann ein Softwarefehler das System immer noch zum Absturz bringen. Wenn weniger als ein Drittel der Knoten ausfällt, wird das System überleben. Wenn jedoch ein Fehler in der Software vorliegt, kann es durchaus sein, dass Sie diese fehlerhafte Software auf mehr als einem Drittel der Knoten installieren.

Answer 2

Ich sehe hier viele mögliche Probleme.

Erstens wurden Ihnen zwei unausgereifte Lösungen zur Prüfung vorgelegt, die in der dargestellten Form schwierig zu verwalten und fehlerintolerant sind.

Zweitens scheinen Sie sich nicht sicher zu sein, wie Sie Datendienste erstellen sollen. Das ist besorgniserregender.

Ich bin mir nicht sicher, wie Ihre Situation im Hinblick auf die beschriebene Umgebung ist, würde aber empfehlen, nichts zu unternehmen und bessere Anforderungen und einen besseren Plan zu haben, um diese zu erreichen, als zufällige Boxen, auf denen viele Datenbanken ohne Backups (live oder anderweitig) laufen.

Wenn Sie sich um Laborinventar sorgen, gibt esvieleEs gibt viele Software, die sich mit diesem Thema befasst. Wenn Sie mit proprietären Eigenheiten eines Anbieters arbeiten, ermitteln Sie dessen Umgebungsanforderungen und finden Sie einen Weg, mit einem gewissen Maß an Sicherheit auf diese Daten zuzugreifen und sie aufzubewahren. Ich versichere Ihnen, dass dies schon einmal gemacht wurde.

Nichts davon wird dadurch erreicht, dass Sie ausschließlich vage Fragen in diesem Forum stellen. Wenn Sie sich überfordert fühlen, sollten Sie sich ein paar Stunden Zeit von einem Berater nehmen, der Ihnen hilft.

Answer 3

In der gegebenen Umgebung erscheint es wichtig, dass es eine einzige Informationsquelle für die Daten gibt. Stimmt das? Das können wir nicht sagen.

Es wird immer Schwachstellen geben. Sie müssen Ihre Konstruktion auf das ausrichten, was akzeptabel ist.

Sie müssen die Einschränkungen Ihres Systems berücksichtigen. Muss es eine einzige Datenquelle geben? Kann ein Gerät offline auf das Inventar zugreifen? Kann ein einzelner Serverausfall toleriert werden? Kann das System einen kurzen Betrieb im Nur-Lese-Modus tolerieren?

Sobald Sie diese Einschränkungen haben, werden Sie feststellen, dass dieWieder Systemgestaltung ergeben sich aus den Zwängen.