Raspberrypi.md: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Root (Diskussion | Beiträge) |
Root (Diskussion | Beiträge) |
||
Zeile 43: | Zeile 43: | ||
== Revolution == | == Revolution == | ||
* Revolution ersetzt den Master, alle Nodes müssen zustimmen | * eine "Revolution"-Situation ersetzt den Master, alle Nodes müssen zustimmen | ||
* alle Nodes müssen in einem tadellosen Zustand sein | |||
== Hardware == | == Hardware == |
Version vom 7. November 2019, 17:05 Uhr
- Dies beschreibt das Konzept eines RAID-6-Systems bei dem ...
- ... ein Raspberry Pi 4 den Master bereitstellt
- er betreibt ein ext4-Dateisystem mit er Freigaben durchführt
- er hat selbst kein Speichermedium,
- er ist an einen internen Switch angeschlossen, an den auch alle Nodes gekoppelt sind
- er berechnet niemals P oder Q
- ... viele Raspberry Pi 4s als Nodes arbeiten
- sie haben eine feste Rolle inerhalb des RAID-Verbundes
- die haben nur eine Platte mit einer Partition angeschlossen
- sie berechnen P und Q immer selbst anhand ihrer Rolle und der Sektornummer
- ... ein Raspberry Pi 4 den Master bereitstellt
write(Sector,Data):boolean
- Der Master sendet ein Datagram mit
- WRITE
- Sector#
- Data
- auf den Switch. Das Datagram ist nicht an einen gewissen Node gerichtet, es ist für alle
- Ein Node kann anhand seiner "Rolle" erkennen, ob er
- raw oder P oder Q and der Stelle "Sector" speichern muss.
- Nur die 3 Betroffenen Nodes senden das Ack, der Master weiss wer das sein sollte
read(Sector):Data
- Der Master führt eine Statistik "wer" einen read beantworten muss
- Ich bin mir jetzt unsicher wie das im raid-6 Code gemacht wird
- wird immer raw,P und Q gelesen, also 3 Platten?
- oder nur raw,P wegen der Kosten?
- es ist wiederum klar "wer" für einen gewissen Sektor verantwortlich ist
- Node "raw" schickt die Daten ins Netz
- Node "P" und Node "Q" lesen die Daten und prüfen ob diese stimmen, senden ihr ACK an den Master
- wenn beide zustimmen (nur ein kurzes OK) sind die Daten auch für den Master valide
Spares
- Spares lauschen nur auf den Master und haben ihre Platte deaktiviert
Trainee
- Trainees arbeiten im Idle immer daran die Rolle eines Nodes übernehmen zu können
- Dann ersetzen sie diesen und sind ab dem Moment Node
Revolution
- eine "Revolution"-Situation ersetzt den Master, alle Nodes müssen zustimmen
- alle Nodes müssen in einem tadellosen Zustand sein
Hardware
- Es wird ein Switch verwendet der per VLAN-ID ein privates Netz betreibt
- Der Switch hat einen "external" Port ohne VLAN-ID, das ist der eigentliche Anschluss des NAS
- Alle Worker sind identisch aufgebaut (die Platte des Master ist unbestückt)
- Es gibt 5 Status LED
- read-Aktivity
- write-Aktivity
- Master good/fail
- Node good/fail
- Replace me
Historie
- erstes Konzept am Donnerstag 07.11.2019