Inhaltsverzeichnis

Bei einer eigenen Object-Storage-Plattform entspricht die erforderliche Nutzkapazität nicht der Summe der eingebauten Datenträger. Zwischen der Raw Capacity und der für Nutzdaten verfügbaren Kapazität liegen unter anderem das verwendete Schutzverfahren und systemspezifische Reserven. Aus den Nutzdaten ergibt sich über den Overhead des Schutzverfahrens und eine System- beziehungsweise Betriebsreserve die tatsächlich erforderliche Raw Capacity. Die konkrete Berechnung ist implementationsabhängig. 

[BILD 1: Schichtdarstellung von Nutzdaten zu Raw Capacity. Vier übereinanderliegende Blöcke, von unten nach oben zunehmend breiter: Nutzdaten, Data Protection Overhead, System- und Betriebsreserve, erforderliche Raw Capacity. Rechts daneben eine Beschriftung, dass die relative Breite der Blöcke implementationsabhängig ist und nicht maßstäblich dargestellt wird.] 

Replikation 

Bei n-facher vollständiger Replikation existieren n physische Kopien der geschützten Daten. Ohne weitere Overheads ergibt sich theoretisch eine Raw Capacity aus Nutzdaten multipliziert mit dem Replikationsfaktor. Bei drei vollständigen Kopien würden für 1 PB Nutzdaten theoretisch 3 PB physische Kapazität allein für die Datenkopien benötigt. 

Das ist noch keine vollständige Systemdimensionierung, weil zusätzliche Reserven und systemspezifischer Overhead fehlen. 

Erasure Coding 

Die SNIA beschreibt Erasure Coding als Fehlerkorrekturverfahren, das über algorithmische Codes Paritätsdaten berechnet und Datenresilienz effizienter erreicht als eine Spiegelung. Moderne Verfahren erlauben dabei einen konfigurierbaren Ausgleich zwischen verfügbarer Kapazität, Performance, Redundanz, Integritätsprüfung und Rebuild-Zeit. 

Technisch verteilt Erasure Coding die Daten auf Daten- und Parity-Fragmente. Bei einem Schema mit k Datenfragmenten und m Parity-Fragmenten beträgt die theoretische Storage Efficiency k / (k + m); der zugehörige Expansionsfaktor gegenüber den Nutzdaten lautet (k + m) / k. Ein 8+4-Schema hätte damit eine theoretische Storage Efficiency von 8 / 12, also 66,7 Prozent, und einen Expansionsfaktor von 1,5. Für 1 PB Nutzdaten wären allein aufgrund dieses Schemas theoretisch etwa 1,5 PB physische Kapazität erforderlich. 

Auch diese Rechnung beschreibt nur den mathematischen Schutz-Overhead. Ob und wie ein konkretes Produkt zusätzliche Kapazität für Metadaten, interne Prozesse oder Betriebsreserven benötigt, muss anhand der jeweiligen Implementierung dimensioniert werden. 

Reserve für Rekonstruktion und Erweiterung 

Ein verteiltes Storage-System benötigt nicht nur Platz für die vorhandenen Nutzdaten. Nach dem Ausfall einer Disk oder eines Nodes müssen Daten beziehungsweise Fragmente auf verbleibende Ressourcen rekonstruiert und verteilt werden. Dafür benötigt das System sowohl freie Kapazität als auch I/O- und Netzwerkressourcen. Die Rebuild-Zeit ist damit keine nachgelagerte Betriebsgröße, sondern Teil derselben Auslegungsentscheidung wie Kapazität und Performance. 

Eine Plattform bis unmittelbar an ihre nominelle Kapazitätsgrenze zu dimensionieren, lässt die Anforderungen des Failure Handling außer Betracht. 

Wie viel Reserve erforderlich ist, lässt sich jedoch nicht herstellerneutral als allgemeingültiger Prozentwert festlegen. Der Wert hängt von der konkreten Object-Storage-Implementierung ab, vom Schutzschema, von Clustergröße und Failure Domains, von Anzahl und Größe der Nodes sowie vom Rebuild-Verfahren und vom Erweiterungsmechanismus des Systems. Für ein reales On-Premises-Sizing sind deshalb die dokumentierten Anforderungen und Sizing-Regeln der gewählten Plattform maßgeblich. Wie sich solche Systeme im Betrieb erweitern lassen, behandelt der Beitrag [QUERVERWEIS: Scale-out-Architekturen im Storage].