close
Warning:
Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.
- Timestamp:
-
Mar 3, 2022, 6:34:17 PM (5 years ago)
- Author:
-
Rüdiger Kupper
Legend:
- Unmodified
- Added
- Removed
- Modified
-
|
initial
|
v1
|
|
| 5 | 5 | Oder wir lösen die RAIDs auf und verwenden die Pkatten einzeln. Damit hätten wir 8 „Bricks“ (Gluster-Terminologie für die Speicherorte, die zusammengeschaltet werden). Mit diesen könnten wir dann jedes beliebige Szenario zwischen 1:8 (nur Verteilen) und 8:1 (nur Replizieren) wählen. |
| 6 | 6 | |
| 7 | | Beispiel: 4:4. Das wäre vom Speicherplatz genau so wie RAID mit kompletten Verteilen (doppelte Speichermenge einer einzelnen Platte). Würde aber Robustheit sowohl gegen Platten-, als auch Rechnerausfall bieten. (Sogar vierfache Replikation start nur zweifacher wie beim RAID). Zudem wäre der Performancegewinn größer, weil jede Datei von vier verschiedenen Platten gelesen werden kann, statt nur zwei wie beim RAID). |
| | 7 | Beispiel: 4:4. Das wäre vom Speicherplatz genau so wie RAID mit kompletten Verteilen (vierfache Speichermenge einer einzelnen Platte). Würde aber Robustheit sowohl gegen Platten-, als auch Rechnerausfall bieten. (Sogar vierfache Replikation start nur zweifacher wie beim RAID). Zudem wäre der Performancegewinn größer, weil jede Datei von vier verschiedenen Platten gelesen werden kann, statt nur zwei wie beim RAID). |
| 8 | 8 | |
| 9 | 9 | Oder 3:5: Hier hätten wir dreifache Redundanz (wie empfohlen) mit entsprechendem Performancegewinn, aber immerhin noch das 1,625-fache des Speicherplatzes einer einzelnen Platte (wenn ich richtig rechne). |